Your PDF is public. Including the one nobody should see

On 24 August I found my own quote on the web. Not the page it belonged to, that one was locked behind a code. The PDF linked from that page. The server’s answer: HTTP 200. Two IBANs in it, along with every price.

I am not enjoying writing this down. But it is the mistake I see most often at clients, and I made it myself.

Why it happens

A website is not made of pages, it is made of addresses. Every file has one of its own. The page /quote/example-ltd/ is one address, and the PDF at /quote-assets/example-ltd/offer.pdf is a second, entirely independent one.

Protect the page and you have protected the page. The document underneath knows nothing about it. It sits in a folder the web server hands out, and hand it out is what the server does the moment somebody asks. No password, no questions.

In my case the protection was actually built rather carefully: the page itself is encrypted and only decrypted in the browser once someone types the code. It just stops precisely at the edge of the page. Whatever lay beside it went out unchallenged.

The galling part: a comment at the top of the file had described this exact hole since day one. A comment, it turns out, is not a brake.

noindex is not a lock

The second half-truth I hear a lot: “the page is set to noindex, nobody will find it.”

noindex is a request to search engines not to list a page in their results. Google honours it. Nobody else has to.

Anyone who knows the address gets in. Anyone who guesses it does too. And addresses are often easy to guess, precisely because we name them tidily: if /quote/miller/ exists, /quote/smith/ is worth a try. Then there are the routes you never think of: the link somebody pastes into a chat. The browser that sends addresses off to a spell-checking service. The archive service holding a copy of your site from last year.

A week later I measured again in the same matter. Nine more pages were sitting there with no protection at all. Every one of them had its dutiful noindex. It made no difference, because noindex was never meant to do that job.

What is probably sitting open on your site

Go through, in your head, everything linked from your website as a file, or ever was:

• Price lists that were only ever meant for resellers
• Quotes and contracts you put up for a client to download
• Registration forms that came back filled in and ended up in the same folder by accident
• Internal lists, phone directories, org charts with private numbers
• The 2023 price list nobody links to any more, but which is still lying there

That last one is the most common. A document does not disappear when you remove the link. It disappears when you delete the file.

Check it yourself, it takes ten minutes

One, the direct test. Right-click a document link on your website, copy the address, open a private window, paste. If it opens, it is public. Done, that is all it takes.

Two, what Google has of yours. Type this into Google:

site:yourcompany.ch filetype:pdf

That lists every PDF on your domain that Google knows about. Try not to jump if there is more there than you expected. The same works with filetype:doc, filetype:xls and filetype:zip.

Three, the folder itself. Ask whoever looks after your website for a list of every file in the public folder. Not the linked ones, all of them. The difference between those two lists is exactly what you forgot about.

What to do next

If you find something that should not be public, renaming will not help and hiding will not either. There are three real options:

Delete it. The best one. If nobody genuinely needs the document any more, get rid of it. Check the address again afterwards, some systems keep a cached copy.

Put it behind a real lock. Most hosting offers password protection for whole folders, applied at the server rather than in the browser. Ask for it; on my own hosting it comes as standard. What matters is that the password is demanded before the file is handed over, not after.

Send it as an attachment. That is the route I chose. A document meant for exactly one person does not belong on a server where anyone can collect it. It travels as an email attachment, and after that it does not exist there any more.

And if something has already happened

If personal data was exposed, meaning names, addresses, dates of birth or health details, that is a breach of data security under the revised Swiss Data Protection Act. You have to report it to the FDPIC if it poses a high risk to the people concerned. That is not a gut call: it depends on what the document contained and how long it was open.

For bank details, tell your bank. An IBAN on its own is not access to your account, but it is half the way to a convincing fake invoice sent in your name.

What I did about it

I built a check into my build process that opens every document being published and reads the text inside it. If it finds bank details, the build stops, wherever the file happens to sit. And any document living in the folder of a protected page has to be explicitly cleared as public, or it never ships at all.

The first version of that check was itself broken, as it happens. It relied on a tool that, faced with a PDF it does not understand, simply returns empty text and reports that all is well. It showed a clean result while having measured nothing. That is the second lesson from all this, and it reaches well beyond PDFs: a green tick only means something if you know what it measured.

Which is also why the search box on its own will not settle this. If site:yourcompany.ch filetype:pdf comes back with nothing, that is not evidence your documents are safe. It is evidence that Google has not indexed them yet, and an unlinked file is precisely the kind it never gets around to. Of the three checks above, only the folder listing actually looks.