2 months free, then $29.95/mo.Start free trial
EstateSalesList.com
Blog

The address, the phone, the card on file

Jeffrey Lind9 min read

Open almost any company profile on EstateSales.org and the page looks ordinary: a business name, a city, a short description, the services on offer. But the page your browser actually receives carries far more than what it shows you.

Tucked into the source of those public, logged-out pages is a block of data the site uses to render itself. On a seller’s profile, that block includes the account owner’s email address and phone number, the street address on file, precise map coordinates, and their billing details, down to the last four digits of the card on the account, its expiration month and year, and the internal subscription identifiers behind it. None of it appears on screen. All of it is delivered to anyone who opens the page.

We found this while researching how the estate-sale industry handles the genuinely sensitive information it collects, and it is worth being precise about what “sensitive” means here. Estate sales happen at people’s homes, often during a death, a downsizing, or a move. The address is the product. Keeping it private until the right moment is a safety feature, not a nicety. So a page that quietly hands out home addresses and payment details to strangers is not a small bug.

A redacted, reconstructed view of the data embedded in a public profile page. The name, city, and state are what you see on screen. Everything marked in red is delivered in the same page and never displayed.

Everything you just saw is synthetic. We have not reproduced any real person’s record here, and nothing on this page identifies an individual. The shape of the data, though, is real: this is the kind of object present in the public source, structured roughly this way, on ordinary profile pages served to logged-out visitors.

It isn’t one page. It’s the whole directory.

A single leaky page is a problem for one person. What turns this into a problem for everyone is how the pages are addressed. Profiles live at simple, sequential numeric URLs, one number per account. There is no gap to guess and no token to hold. You can start at one number and count upward, and each step lands on another real record.

That applies to buyers as well as sellers. A plain shopper who created an account, with no company and no listings, still has a profile page that carries their name, email, phone, and the timestamp of their last login. In practice, the entire membership, everyone who ever signed up, is reachable by walking a list of numbers in order.

Sequential IDs mean the site can be read front to back. Increment the number, load the next record, repeat, until the whole account base has gone by.

The lock that isn’t locked

Here is the part that shows the team understood the risk. EstateSales.org built a real privacy feature: when a company publishes a sale, it can keep the exact street address hidden until a chosen reveal date. Shoppers see the general area, and the full address appears automatically when the time comes. It is a thoughtful control, and the public web page honors it correctly.

The data API sitting behind the same site does not. Request the sale through its public JSON endpoint and the street address and coordinates come back in full, reveal date or not. The lock is on the front door while a window is left open around the side. Anyone who reads the API instead of the page gets exactly what the feature was built to withhold.

Same sale, same privacy setting. The rendered page withholds the exact address; the public API returns it anyway.

How something like this happens

None of this requires bad intent, and it almost never comes from one careless line of code. It comes from a single, tempting shortcut: handing the browser the whole database record and letting the page decide what to show. On screen, the page is disciplined. It renders the name and the city and leaves the rest alone. But the rest already arrived. “Not displayed” and “not sent” are very different things, and the gap between them is exactly where this data lives.

The hidden-address API is the same mistake wearing different clothes. One part of the system enforces the rule; another part, serving the same data, never got the message. When privacy is something you apply at the edge, after the data has already been gathered up and sent out, you have to remember to apply it everywhere, every time, forever. Sooner or later one path forgets.

Privacy is a decision the server makes first

The durable fix is to change where the decision happens. A public page should be built from a deliberately public view of the data: a small object assembled on the server that contains only the fields a stranger is meant to see, and nothing else. The email, the phone number, the home address, the card details never enter that object, so they can never leak from it. There is no field to forget to hide, because the private fields were never in the room.

The difference isn't a filter bolted on at the end. It's what the server chooses to assemble in the first place.

This is the principle we build EstateSalesList.com around, and it is why we felt we could write about this honestly. Public pages are drawn from public data by design. The sensitive things people entrust to us aren’t withheld from the page after the fact; they never travel to it. That is what “private by default” has to mean to be worth anything.

Why we’re publishing this

We did not go looking for a competitor’s mistakes. We found this, confirmed it carefully using only what any visitor’s browser already receives, and reported it privately to the company’s leadership first, because that is the right order to do things in. We gave them time to respond and to fix it. We did not hear back.

So we are writing it up now, in public, because the people affected are real and they haven’t been told. Estate-sale sellers are often older, often dealing with a loss, and their home address and payment information are precisely the things a scammer wants. They deserve to know that data has been sitting in the open, and they deserve an explanation in plain language of what that means and what they can do.

What we are deliberately not doing

  • We are not publishing anyone’s data. Every example on this page is fabricated. No real names, emails, addresses, or card numbers appear anywhere in this post.
  • We are not publishing a how-to. This explains a class of problem and why it matters, not a recipe for collecting anyone’s information.
  • Our research was read-only. We looked at what a normal browser is already handed when it loads a public page. We did not break in, move data in bulk, or touch anything behind a login.

If you’ve used EstateSales.org

Until the company confirms a fix, the safest assumption is that anything you gave them, your name, email, phone, address, and the fact that you hold a card on file, could have been read by someone. A few sensible precautions follow from that.

Be skeptical of unexpected calls, texts, or emails that already seem to know your details; knowing your name, address, or the last four digits of your card does not mean the sender is legitimate. Never share a full card number, security code, or password in response to an incoming message. If you keep a card on file there and want peace of mind, ask your bank about a replacement number. And if you list sales, treat the hidden-address feature as weaker than it looks until the company says otherwise.

We would genuinely rather this were fixed than talked about. If anyone at EstateSales.org wants to compare notes, our door is open. The point of writing this is not to score a point against another company. It is that the people whose information was exposed are the ones who never got a say, and they are the reason to say something now.