Securing a DoD contractor: Finding a multi-tenant authorization vulnerability (opens in new tab)

> So you get people deploying API keys client side and dbs without rls. Or deploying service keys client side when they should be anon. I mean really basic stuff.

Claude Code will do this, and actively encourage bypassing any verification before pushing to prod. I saw that first hand with its attempted handling of a major CIAM provider, and then Vercel using whatever OAuth provider in the ol' transitive breach

That is common knowledge now, right? Or am I just smoking yellow tops

Yep, this has been my experience over 15 years in startups as well. There are barely any punishments, so there is no incentive for startups to change how they operate.

I used to work at a startup that handled medical records. A HIPAA breach would have wiped out the company through reputation damage — because our customers were also subject to HIPAA and couldn't possibly hire a startup with a track record of HIPAA breaches.

In my personal assessment some individuals within leadership at this startup were highly risk-tolerant. I speculate that had those individuals been in leadership at other companies not subject to HIPAA, security practices would have been as lax and irresponsible as what's being described as the norm in this thread.

However, because of HIPAA, security practices at this company were fair-to-middling. There were certainly weak areas and mindless box-checking a la SOC-2, but it wasn't a complete shitshow. Those of us in the engineering deparment who cared were able to raise concerns and not have them dismissed, and were generally allowed to do things the right way.

My takeaway: when there are actual severe penalties for privacy breaches, startups may not be so cavalier with your data.

Honeastly though, I get it. If you have headcount for two people, do you want one of those people to be a DBA and another to be a platform architect? Whos going to actually make the app.

I genuinely think the problem is that frameworks don't do this for you. Why should you need a DBA and platform architect to make a multi tenant CRUD app, pretty much every one does the same thing..

More often than not security minded people are encouraged to focus on things that get the product to market faster instead.

And auth checks on the frontend. Or sometimes on the backend, but only on list pages. Or tables that still use INTEGER PRIMARY KEY AUTOINCREMENT in 2026 (which is one way to definitely disprove your statements about 1000x growth).

In your opinion, is the lack of attention on security due to speed-bias or not having the expertise? For a startup / sole entrepreneur with very limited resources, what would be your advice?

Should have been handled better, but some context is necessary:

If your name is associated with a startup in a visible leadership position you will get mass-spammed from people claiming to have discovered critical vulnerabilities in your system. When you engage with them, the conversation will turn into requests to hire them for their services.

So the CEO handled it poorly, but it's also not a great choice to withhold the details of the vulnerability in initial contact. If the goal was to get something fixed it should have been included in an easy-to-forward e-mail that could have been sent to someone who could act upon it.

Anyone who works with security or bug bounties can tell you that the volume of bad reports was a problem before LLMs. Now that everyone thinks they're going to use LLMs to get gigs as pentesters the volume of reports is completely out of control.

I keep getting emails with the content like: "I found a critical bypass vulnerability in your app what is the appropriate channel to disclose it, and do you have a bounty program?"

I tried engaging and replying to them, and it inevitably turns into: "Yeah, we don't actually have the vulnerability, but you are totally vulnerable, just let us do a security audit for you".

I have a pre-written reply for these kinds of messages now.

The number of spam "I found a vulnerability" emails you get as a SaaS operator is ridiculous, they never offer any proof of a vuln and just want you to confirm you have a bug bounty program (in which case they'll start scanning afterwards), or to pay ahead of time for the information or they'll threaten to release it.

Their response isn't damning to me. It sounds like they just assume they're one of these spammers.

i have even more damning ones.

When the "good Samaritan" do not go to the vendor, they go to the client (i.e., they do not contact the DIB company, they contact the Gov agency).

I have seen government contractors getting pilloried, losing their livelihood when this happened. And, yes there is always a "quick fix offer" by the "good Samaritan" to the vendor and promised re-assurance to the Gov agency, only if this misguided vendor would go with their solution.

It is also not unusual to find out later on, that the identification or even the resource reported on was wrong - but by this time the Gov agency already punished the contractor and the reporting "good Samaritan" is laughing (sometimes to the bank).

they can get away with unethical vulnerability disclosure because think of the children, the threat to the nation, grandma off the cliff, and <insert your favorite cliche justification of malfeasance>.

Yes, sore subject.

They could sell the next one to an adversary for a lot more money if they're going to act like that.

Andreessen-Horowitz, who most people (and they themselves) refer to as a16z and have the eponymous domain name (a16z.com). They're one of the top VC firms on the planet -- exceedingly relevant to HN audiences and commonly discussed here.

apologies, just a vc firm

One hopes not as this stuff would have come up in even a cursory audit of the product - but it’s kinda like Ratings Agencies / Moody’s in 2008 right now until a big breach that occurs post-cert and they lose their credibility.

ISO compliance tells you almost nothing about the security of the product being developed, just about the processes in place at the company developing the product.

To answer the first question, a number of veteran independent researchers probably wouldn’t have touched such a system. Plenty of companies will send their lawyers after you if you tell them that you’ve discovered a vulnerability of some sort and wish to responsibly disclose. Even if you do things in good faith, the company has zero reason to assume the best from you and can hold a sword over your head by citing poorly-written laws that lean in their favor regarding computer fraud and abuse.

DoD does appear to offer a “Defense Industrial Base - Vulnerability Disclosure Program” for all public-facing DoD/DoW systems.[1] However, this might not include contractor-controlled assets or services. I cannot view the HackerOne page that it redirects to (login is required) to view more details.

[1]: https://www.dc3.mil/Missions/Vulnerability-Disclosure/DIB-Vu...

> How do independent researchers do this with legal safety?

In my experience it’s usually foreign nationals from third-world countries doing drive-by beg-bounty testing. Presumably they don’t much consider legality.

fixed now

Honestly, I didn't know who Andreessen Horowitz was, until you spelt out a16z

Wait until we understand the depth of the current Mythos zero day situation. We already have an overall idea of what’s to come but I don’t think we can grasp the high level implications the vast array of these vulnerabilities have in store for us. I don’t see/ say this in a doomsday-ish way nor the world coming to an end. It will sting a bit but overall it’s way overdue and spells opportunity for all, imo.

We've been thinking about testing this stuff out as well. Have you had a chance to look into stuff like XBOW/Horizon3?

I know the space is starting to get crowded, but I've been building one and I'd love to get feedback if you have time

Yes. http://shodan.io

Probably based on insider info to some degree; if you already do any sort of work for the DoD, then that tends to help narrow the scope of the search for vulnerable things to exploit.

> It's interesting if AI systems can "spot" these, in the sense of autonomously exercising the application and "understanding" obvious failed authz check patterns. But it's a "hm, ok, sure" kind of interesting.

I think that misses the bigger point: automated scanners have gotten better and the floor for issues has risen. Security@ mailing groups are going to be getting more messages that aren't just noise from people running automated scanners.