[Ir]rational Compliance Requirements (and how they harden your environment)

November 10, 2025

🐦 Share

Been building out a compliance program lately—SOC 2 and some others. Part of something bigger I'm working on, more on that later.

Going through this has been clarifying, just not in the way I expected.

The Disconnect

Here's a typical requirement:

"A list of commonly-used, expected, or compromised passwords will be maintained by the designated official, and will be updated <FREQUENCY>."

Someone manually maintains a list of bad passwords. Updated quarterly.

Meanwhile, HaveIBeenPwned has 15 billion compromised passwords. Updated constantly with a free API.

This is what frustrates security people. Compliance requirements feel dated, bureaucratic and disconnected from how attacks work. The natural reaction is to do the minimum, pass the audit, focus on "real" security.

And for most organizations, that's probably right. If you're still dealing with SQL injection, unpatched systems, and exposed credentials, a quarterly password list isn't your problem.

The Misunderstood Controls

Take login Cross-Site Request Forgery (CSRF) for example — an attack targeting the authentication process.

Compliance frameworks push CSRF protection hard. Every login form needs tokens. Shows up in audits, gets flagged in scans, becomes a requirement.

For most organizations, login CSRF is seen as nonsense. Forcing someone to log into their own account doesn't exploit anything meaningful. It's marked Info or Low.

Or take Self Cross-Site Scripting (Self-XSS), where an attacker convinces a user to execute JavaScript in their own browser. It's not a vulnerability that can be exploited by simply clicking a link—user action is required. As a result, bug bounty programs typically reject self-XSS reports, and security teams frequently dismiss them: "If the exploit requires the user to attack themselves, we don't consider it a real risk."

Dated controls feel laughable—right up until maturity makes them the last exploitable path.

On their own, issues like these seem minor. Login CSRF gets marked Info or Low. Self-XSS is typically dismissed.

Here's a real-world attack chain where these controls become critical, as demonstrated in research by matanber and discussed in this video:

1

Force Authentication

Force the victim to authenticate into an attacker-controlled account via login CSRF

2

Trigger Self-XSS

Trigger self-XSS in that account

3

Set Path-Specific Cookies

Use JavaScript execution to set path-specific session cookies

4

Cookie Jar Overflow

Clear the victim's cookies via cookie jar overflow (browsers have a ~300 cookie limit)

5

Strategic Cookie Placement

Set the attacker's session cookie only for specific paths

6

Redirect Victim

Redirect the victim away

7

Delayed Execution

Days later, the victim logs back into their own account. They're authenticated everywhere... except the one path where the attacker's cookie still takes precedence

8

Full Account Takeover

The next time they navigate to that path, the self-XSS triggers, but now with access to their legitimate session in all other paths

The Chain is what makes the unique naunces an actual problem

• Cookie jar overflow is just a browser quirk.
• Path-specific cookies are by design.
• Self XSS is generally not seen as impactful.
• Login CSRF is seen as harmless

But once you've hardened everything else, these combinations become your exposure. In a mature organisation, the chain is what matters.

The Maturity Paradox

The more mature your security program becomes, the more these "nonsensical" compliance controls actually matter.

Not because the compliance framework is sophisticated. But because at higher maturity, you've handled the obvious stuff. What remains are the subtle interactions, the medium-severity issues that chain together, the edge cases that only matter in specific contexts.

And compliance requirements often cluster around exactly those layers. Authentication. Authorization. Session management. Data handling.

The requirements are still dated. The reasoning is still bureaucratic. But they're pointing at the places where sophisticated exploitation happens in hardened environments.

How "pointless" compliance actually hardens your environment

What looks like checkbox theater often points at the layers where mature orgs still bleed: authentication state, session lifecycle, and authorization transitions. Use the compliance mandates as a design surface and they compound security instead of paperwork.

Most organizations do the bare minimum on compliance, not realizing where the controls actually matter. That’s fine early on—you have bigger risks.

But mature organizations that use compliance to deliberately build strong foundations reap real benefits. Not because of compliance itself, but because it forces you to address critical layers with intent.

A quarterly password list is still silly. But if it teaches you about authentication, session handling, and where medium-severity issues lurk, you’re building resilience that matters at scale.

SOC 2 made this clear: the requirements aren’t groundbreaking, but they push you to systematically think through layers and relationships—before an incident forces you to.

More soon on what I’m building.

---

Thinking about these problems? Let's talk.