Build
October 12, 2026 · 5 min read
Is “Anyone With the Link” Safe? What I Fixed
Anyone with a Verilay report link could read it. I found they could also change it. What I fixed, what I didn’t, and three questions for your own app.
Verilay reports are shared by link. Run a scan, get a link, send it to whoever needs to see it. I like that. No account, no password, nothing to remember.
But I found out what that link quietly means. Anyone who has it can open the report. That part is on purpose. For a long time, though, anyone who had the link could also change the report. Nobody told me. I found it by going through my own report pages the way I’d go through someone else’s app.
It’s fixed now. Here’s what was wrong, what I changed, and what this does not fix.
Reading something and changing it are different permissions
You know the difference in a shared document. “Anyone with the link can view” is one setting. “Anyone with the link can edit” is another. I’d built the second one without realising, for pages that were only ever meant to be the first.
A report link is long and random, so it’s hard to guess. That’s good. But hard to guess is not the same as allowed. If knowing the link is all it takes to change a report, then everyone you send it to can change it. So can everyone they forward it to, and anyone who spots it in a screenshot.
What I found
- Delete didn’t delete. The delete button asked the server to remove a report. The server answered “OK” and left the report online. One line of code the delete step needed had never been added, so it failed quietly, and the server said OK anyway. That had been the case since early June.
- Anyone with the link could change a report. They could overwrite it with something else, or attach a different fix list to it. The “mark as verified” and delete actions had no check either. They were only protected by the fact that they were broken.
- Text from your code could become part of the page. A report is built partly from what an AI reads in your code. If any of that text contained web-page code, and the page dropped it in as-is, a browser opening the shared report could run it. In my own test, I planted 15 pieces of that kind in a report. The old page let 14 of them through as live page code. None get through now.
- Two smaller leaks. The README badge showed the grade for any repo name you typed, including private code someone had scanned by uploading a ZIP. And if you left your email in the feedback box, it was stored with the report, where anyone holding that report’s link could read it.
What I changed
- Each new report gets a private key. It’s created when you run the scan and given only to the browser that ran it. Verilay keeps just a fingerprint of the key, so I can’t read it back either. Changing a report, marking a finding verified, or deleting it needs that key. Deep scan reports are also tied to your account, so you can manage them when you’re signed in.
- Everything on a report page is treated as plain text, not page code. The diagram is rebuilt from a short list of shapes I know are safe.
- Delete is checked. If a report is still there, you’re told, instead of getting an OK. A deleted report is gone from its page, the printable IT pack, the download, and its grade no longer shows on the badge.
- Feedback emails and comments are no longer part of the public report data. They’re also length-limited.
- Reports now say when they were scanned, to the minute, in UTC. I noticed an older deep scan report that didn’t say when it was run. A security result without a date is half a result.
What this doesn’t fix
- The link still opens the report for anyone who has it. Reports aren’t listed anywhere and search engines are told to ignore them, but a link is not a login. Don’t send a link to a report about code you wouldn’t show that person.
- Reports made before this change are now read-only. They have no key, so nobody can change or delete them from the site, including you. If you want one removed, email [email protected] with the link and I’ll do it.
- The key lives in your browser. If you clear your site data or switch browsers, you can’t delete that report yourself any more. Email me and I’ll do it.
- I haven’t had a report of anyone using these. I also can’t prove nobody did. That’s why I fixed them instead of arguing about them.
Three questions for your own AI-built app
Verilay’s AI review looks at login and access in general, but it doesn’t yet check these specific things automatically. I’m working on that. Until then, you can ask your AI builder:
- “For every action that changes or deletes something, what proves the person asking is allowed to?” Knowing an ID or a link isn’t proof.
- “Where does text that didn’t come from me end up on a page, and is it treated as plain text?” That includes what visitors type, what other systems send, and what an AI writes.
- “After I delete something, can I still reach it by its link, an API or a search?” Try it yourself. Delete something, then open the old address.
That last one took me far too long to try on my own tool. It’s the same lesson as the hole I found in the second fetch: the part that looks handled is the part I stop checking.
The changelog has the short version. Verilay’s code is public at github.com/ekbm/verilay. If there’s another door I haven’t found, I’d rather you told me.
Verilay is free at verilay.dev — no account needed.
Paste in a GitHub link, a ZIP from Lovable or Replit, or your live app’s address, and
it will tell you in plain English what your app is made of and what’s worth worrying
about. The code is public at
github.com/ekbm/verilay.