Broken Access Control in Java and Spring: A Security Architect's Perspective

Part 1 covered horizontal privilege escalation and IDOR, walking through ownership validation, Spring Security method-level authorization, and the bypass techniques that keep showing up in assessments. Part 2 moved on to vertical privilege escalation, role-based and attribute-based access control, multi-step process flaws, mass assignment, and how to test all of it.

This part is different. It steps away from code and looks at the program that has to sit around the code. Fixing an access control bug is the easy part once you know how. The harder problem is building an organization where those bugs rarely reach production, get caught fast when they do, and get closed before anyone outside the company notices.

A lot of what surrounds that goal is the same no matter which vulnerability class we are talking about. The metrics, the SDLC gates, the remediation SLAs, the training program, and the incident response lifecycle do not change because the bug is an IDOR rather than a SQL injection. I wrote all of that up separately in Building an Application Security Metrics Program, and I am going to point back to it instead of repeating it here. This post stays on the parts that are genuinely specific to access control: how the threats differ, how to score and prioritize the findings, where the compliance lines fall, and which architectural controls actually move the needle.

One framing worth holding on to before we start. Broken Access Control sits at A01:2025 in the OWASP Top 10 2025, the top of the list. That ranking is not arbitrary. Authorization has to be correct in every endpoint, for every resource, on every access path. Get it right ninety-nine times and wrong once, and the once is the breach. That asymmetry is the whole reason this category refuses to go away.

1. Threat Modeling Access Control

Controls come after threats, not before. Before we decide where to spend effort, we need a clear picture of what access control failures actually look like in our applications, because they are not all the same animal and they do not all hurt the same way.

Attack Scenarios and Business Impact

Horizontal data breach. An attacker exploits an IDOR to read another user's data. Orders, messages, documents, whatever the resource happens to be. The dangerous version is automated: the attacker walks through thousands of identifiers before anyone notices the traffic. In a healthcare context, a single horizontal failure that exposes patient records pulls HIPAA breach notification into play, along with the regulatory exposure that comes with it. The cost here is rarely the one breach. It is the notification, the legal time, the churn, and the trust that does not come back cheaply.

Vertical escalation to admin. A regular user becomes an administrator. Now they can reach every account, change configuration, create backdoor users, switch off security controls, or dump the database. This is the worst case because it tends to be total. It is not one customer's data, it is all of it, plus the ability to stick around and the ability to destroy on the way out.

Multi-tenant boundary violation. In SaaS, one tenant reaches another tenant's data. The math is brutal: a single isolation flaw does not expose one customer, it exposes the whole book of business. Enterprise buyers ask hard questions about tenant isolation precisely because they understand this, and a public failure here can be existential for the vendor.

Business logic bypass. The attacker stays inside their own data but breaks the rules of the workflow. They approve their own request, skip a required step, or sidestep a segregation-of-duties control. The damage is fraud and failed audits rather than a classic data dump, which is why financial and public-company applications get extra scrutiny on this one.

API abuse at scale. An unprotected or under-protected endpoint gets automated. Manual IDOR exploitation pulls a handful of records. API abuse pulls millions before detection fires. Scale is the multiplier that turns a finding into a headline.

STRIDE for Access Control

Run access control through STRIDE and it lights up almost every category, which is part of why it ranks where it does.

STRIDE Category	How Access Control Failures Show Up
Spoofing	Acting as another user through IDOR, accessing resources as if you owned them
Tampering	Modifying records that belong to other users without authorization
Repudiation	Reaching admin functions that let an attacker rewrite or wipe audit trails
Information Disclosure	Reading data across users, tenants, or privilege levels
Denial of Service	Deleting other users' resources, locking accounts through admin functions
Elevation of Privilege	A regular user reaching admin functions, a tenant admin reaching system config

A single access control flaw can land in several of these at once. An IDOR that allows writes is information disclosure and tampering and, depending on the field, elevation of privilege. That breadth is the point.

Attack Tree

A rough attack tree is useful less as documentation and more as a map of where to put obstacles.

Every leaf is a place a control could live. Defense in depth means none of those leaves is the only thing standing between an attacker and the data. If one check is missing, the next layer still says no.

Threat Actors

Knowing who comes after access controls helps decide what to build first.

External attackers run automated tools looking for low-effort IDOR and obvious vertical escalation. They want easy targets and move on if you are not one. The defense that frustrates them is boring and effective: kill the obvious findings through automated testing and secure defaults so the scanners come up empty.

Authenticated malicious users have real accounts and are deliberately trying to exceed what those accounts allow. They understand the application and go after specific high-value resources, not random IDs. Thorough authorization at the object level and anomaly detection on access patterns are what catch them.

Curious insiders mean no harm but poke around past their lane. A support agent checks a celebrity's account. A developer opens production data to satisfy a hunch. Least privilege, audit logging, and periodic access reviews are the relevant controls, and none of them are technical heroics.

Compromised accounts arrive through phishing, credential stuffing, or malware. The credentials are legitimate, the intent is not. Behavioral anomaly detection and re-authentication on sensitive operations are the difference between a quiet takeover and an early alert.

2. Risk-Based Prioritization

Not every access control finding deserves to interrupt someone's day. The job is to rank them honestly against risk and against the capacity we actually have to fix things.

Putting CVSS in Context

CVSS gives us a starting number, but the raw base score ignores where the vulnerability lives. An IDOR in an internal expense tool and an IDOR in a customer payment API can carry the same base score and represent completely different business risk.

A horizontal IDOR that exposes data usually scores in the 6.5 to 8.1 range. It is network reachable, low complexity, and needs only a logged-in account, with no user interaction. Confidentiality impact is high because you are reading someone else's data, and whether integrity climbs depends on whether the flaw allows writes as well as reads. Vertical escalation to admin runs higher, roughly 8.8 to 9.9, because the scope changes: admin access reaches beyond the attacker's own boundary and affects everyone.

The base score is where the conversation starts. The environment is where it gets useful. Cardholder data brings PCI-DSS into the picture, health records bring HIPAA, EU resident data brings GDPR, and each of those shifts the real severity regardless of what the calculator said. Population matters too. A flaw touching a hundred internal users is not the flaw touching ten million customers. And compensating controls count: rate limiting, anomaly detection, and audit logging do not fix the bug, but they change how likely it is to be exploited at scale and how fast we would see it.

A Risk-Scoring Model for Access Control

The shared SLA tiers, escalation paths, and exception handling all live in the metrics program post, so I will not restate them. Access control findings slot into the same severity tiers as everything else. What is worth keeping here is the weighting we use to turn an access control finding into a number, because the factors are tuned to this class.

Factor	Weight	Scoring Criteria
Data Sensitivity	25%	PII/PHI/PCI = Critical, Business Confidential = High, Internal = Medium, Public = Low
Access Scope	25%	All users or tenants = Critical, Subset = High, Single resource = Medium
Exploitability	20%	No auth = Critical, Auth required = High, Complex chain = Medium
Business Function	15%	Payment or Auth = Critical, Core features = High, Supporting = Medium
Detection Capability	15%	No logging = High risk, Logging without alerting = Medium, Active detection = Low

Access scope carries as much weight as data sensitivity here, and that is deliberate. The defining feature of an access control bug is how far it reaches. A finding that exposes one record is a problem. The same flaw that exposes every record through enumeration is a different problem wearing the same code.

Triage Notes Specific to Access Control

A few things shift the priority beyond the raw score. If logs show active enumeration, the finding jumps the queue no matter what the model says. Fix complexity cuts both ways: a missing @PreAuthorize is a one-line change that can ship well inside the SLA, while a flaw rooted in the authorization model itself may need a phased approach. And clustering matters more for this class than most. Several access control findings in one module almost always point at a shared root cause, an authorization helper that everyone copied or a base controller that skips the check. Chase the root, not the symptoms.

3. Compliance Mapping

Access control requirements run through every major compliance framework, usually as one of the load-bearing controls. Knowing where the lines fall makes audits less painful and makes the case for investment easier to defend.

PCI-DSS 4.0.1

For anyone touching cardholder data, Requirement 7 is the access control requirement, and version 4 sharpened it.

Requirement	Access Control Relevance
7.1	Processes and mechanisms for restricting access to system components and cardholder data are defined and understood
7.2	Access is appropriately defined and assigned, including a documented access control model and least privilege
7.3	Access to system components and data is managed via an access control system
7.2.4	User accounts and access privileges reviewed at least every six months
8.3	Strong authentication for users and administrators is established and managed
10.2.1.1	Audit logs capture all individual user access to cardholder data
11.4	Internal and external penetration testing, which exercises access controls

Version 4 expects a documented access control model and regular reviews, not just controls that happen to exist. The defined model lives in 7.2.1, and the periodic review of accounts and access privileges, at least once every six months, comes from 7.2.4. Both were additions over the older 3.2.1 standard. An IDOR exposing cardholder data is a compliance violation with teeth: fines, higher assessment costs, and in the bad cases, the loss of payment processing privileges.

SOC 2 Trust Service Criteria

For SaaS going through SOC 2, the common criteria around logical access are where authorization gets examined.

Trust Criteria	Access Control Relevance
CC5.1 / CC5.2	Selecting and developing control activities, including general controls over technology
CC6.1	Logical access security software, infrastructure, and architecture that protects information assets
CC6.2	Users registered and authorized before credentials are issued, with access revoked and periodically reviewed
CC6.3	Access granted, modified, and removed based on roles, least privilege, and segregation of duties
CC6.6	Logical access measures protect against threats from outside the system boundary
CC6.7	Transmission, movement, and removal of information restricted to authorized users and protected in transit

Auditors want to see how authorization is implemented in the application, how access gets reviewed, and what evidence proves the controls work. Be ready to show how Spring Security annotations enforce authorization, where the authorization service encodes the business rules, and what the tests assert. One practical note: undocumented access reviews under CC6.2 and CC6.3 are among the most common evidence gaps, so a dated record of who was reviewed and what changed carries more weight than a polished policy nobody follows.

GDPR

When an access control failure exposes personal data of EU residents, several articles come into play at once. Article 5(1)(f) sets the integrity and confidentiality principle and requires appropriate security for personal data, so a demonstrable IDOR is evidence the technical measures were not good enough. Article 25 requires data protection by design and by default, which means authorization belongs in the build from the start rather than bolted on after a finding. Article 32 calls for technical and organisational measures appropriate to the risk, plus documentation that shows they work. Articles 33 and 34 set the notification clock: seventy-two hours to the supervisory authority after becoming aware of a breach, and notice to affected individuals without undue delay when the breach is likely to be high risk to their rights.

The fines split into two tiers, and which one applies is not always the one people quote. The security and notification duties under Articles 25, 32, 33, and 34 fall in the lower tier, Article 83(4), capped at ten million euros or two percent of global annual turnover, whichever is higher. The integrity and confidentiality principle in Article 5 is a different animal. It is a basic principle of processing, which puts it in the upper tier under Article 83(5), where the ceiling is twenty million euros or four percent of global turnover. Regulators increasingly cite the Article 5 breach alongside the Article 32 security failure that allowed it, and that pairing is what drags exposure into the higher tier. There is one more wrinkle that tends to get an executive's attention. Since the 2023 CJEU Volkswagen ruling, the turnover behind that four percent is the entire corporate group's worldwide turnover, not just the subsidiary where the bug lived.

HIPAA Security Rule

For applications handling protected health information, the technical safeguards under 164.312 are the relevant ones.

Safeguard	Access Control Requirement
164.312(a)(1)	Access control: allow access only to authorized persons or software programs
164.312(a)(2)(i)	Unique user identification for tracking (required)
164.312(a)(2)(ii)	Emergency access procedure (required)
164.312(a)(2)(iii)	Automatic logoff after inactivity (currently addressable)
164.312(a)(2)(iv)	Encryption and decryption of PHI (currently addressable)
164.312(d)	Person or entity authentication

HIPAA does not name specific technologies. It wants access controls that match the risk and that you can demonstrate. An IDOR exposing patient records triggers notification under the Breach Notification Rule and opens the door to civil monetary penalties under the Enforcement Rule.

One development worth keeping on the radar. The Security Rule has not changed in substance since 2013, but at the end of 2024 the HHS Office for Civil Rights proposed an overhaul, and the proposal lands directly on this table. It would remove the addressable versus required split and make every implementation specification mandatory, with limited exceptions, so automatic logoff and encryption would no longer be optional in practice. It would also add an explicit multi-factor authentication requirement for access to ePHI, plus asset inventories, network maps, vulnerability scanning, and penetration testing. As of mid-2026 the proposal is still not final. OCR is working through several thousand public comments, the original spring 2026 target has come and gone with nothing published, and the current rule still governs. The direction is clear enough to design toward: treat encryption, automatic logoff, and MFA as required rather than discretionary, since that is where the rule is heading.

What to Keep for Auditors

The evidence that actually shortens an audit is specific. Architecture diagrams that show where authorization decisions happen and how data flows past each checkpoint. Written policies that define the authorization model, the roles, and the review and revocation procedures. Code that shows the annotations and the authorization service in action, plus configuration that shows the security settings. Test cases that assert the access control behavior. And the operational trail: completed access reviews, approved exceptions, and incident records for anything that did go wrong. The general structure for assembling and presenting this is in the metrics program post; the items above are the access-control-specific contents.

4. Access Control in the Secure SDLC

The SDLC machinery, the four gates from pre-commit through pre-production, the security champion review, the build-fails-on-critical rule, all of that is covered in the metrics program post and applies here unchanged. What follows is only the access-control-specific behavior to layer onto those gates.

The most important decision happens early, in design, and no scanner will make it for you. Where do authorization decisions get made, controller, service, or repository? Is there one authorization service that everything routes through, or is the logic scattered across controllers waiting to drift apart? How does an authorization rule get tested, and what happens when a check fails? Settle the authorization model before implementation starts, because retrofitting consistency onto a dozen inconsistent controllers is far more expensive than agreeing on the pattern up front.

At the automated gates, the access-control-specific content is the rule set. Generic SAST will not flag a missing ownership check on its own. Custom Semgrep rules carry the weight here: rules that flag controller methods without an authorization annotation, and taint-mode rules that follow a path variable into a repository call without an intervening ownership check. The pre-commit gate should run the high-confidence, low-noise subset of these so feedback is instant and developers do not learn to bypass it. The pull request gate is where a human looks at anything touching the authorization service, because broken access control is the category where automated tools are weakest and human judgment pays off most. At pre-production, authorization-focused testing earns its place for major releases, since IDOR and vertical escalation are exactly the things a manual tester finds that a scanner walks right past.

Secure Defaults and Guardrails

This is where architecture does real work. The goal is a system where the secure choice is the default and the insecure one takes effort.

Deny by default. Configure Spring Security to require authentication everywhere, then carve out the public endpoints explicitly. Permit-all as the baseline is how endpoints quietly ship without authorization.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/api/public/**").permitAll()
            .requestMatchers("/api/health").permitAll()
            .anyRequest().authenticated()  // deny by default
        );
    return http.build();
}

URL-level deny-by-default is necessary but not sufficient, and it is worth being honest about that. It stops the unauthenticated caller. It does nothing about the authenticated user reaching another user's object, which is the IDOR from Part 1. Authentication at the edge and ownership checks at the object level are two different jobs, and you need both.

A second guardrail worth automating: enforce that controller methods actually carry authorization, so a new endpoint cannot ship without it. ArchUnit can fail the build when a controller method has no authorization annotation and is not explicitly marked as a deliberate public endpoint.

import com.tngtech.archunit.junit.AnalyzeClasses;
import com.tngtech.archunit.junit.ArchTest;
import com.tngtech.archunit.lang.ArchRule;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.security.access.prepost.PreAuthorize;
import org.springframework.security.access.prepost.PostAuthorize;

import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.methods;

@AnalyzeClasses(packages = "com.spothopper.app")  // packages ArchUnit imports and checks
class AuthorizationArchTest {

    @ArchTest
    static final ArchRule controller_methods_must_declare_authorization =
        methods()
            .that().areDeclaredInClassesThat().areAnnotatedWith(RestController.class)
            .and().arePublic()
            .and().areNotAnnotatedWith(PublicEndpoint.class)  // custom marker you define
            .should().beAnnotatedWith(PreAuthorize.class)
            .orShould().beAnnotatedWith(PostAuthorize.class)
            .because("Every controller method must make an explicit authorization decision");
}

The detail that matters for this series: the rule does not exempt GET methods. The original temptation is to wave reads through, but reads are where IDOR lives. A @PublicEndpoint marker forces the decision to be deliberate and visible in review rather than implied by the HTTP verb.

The third guardrail is organizational more than technical. Require authorization logic to flow through approved services rather than getting reinvented per controller. A single authorization service is something you can review, test, and fix in one place. Logic copy-pasted across forty controllers is forty chances to get it subtly wrong.

A Note on Training

The training program structure, the foundational course, the refreshers, the CTF exercises, and how to measure whether any of it works, is in the metrics program post. The only access-control-specific guidance to add is that the examples have to be yours. A developer who works in Spring Security all day will not retain a generic slide about authorization. Show them an IDOR in code that looks like your code, walk them through enumerating IDs against a vulnerable build, then have them add the ownership check. The attacker's-eye view of an IDOR is what makes it stick.

5. Metrics Specific to Access Control

The core metrics, MTTD, MTTR, vulnerability density, recurrence rate, the gate effectiveness numbers, exposure window, and the rest, are defined and explained in the metrics program post, and access control findings feed into all of them the same way every other class does. Two signals are worth tracking specifically for this category because they do not appear elsewhere.

Access control coverage. The percentage of endpoints with verified authorization, broken into the percentage that carry an authorization annotation, the percentage with authorization test coverage, and the percentage of sensitive operations that produce an audit record. For critical applications the target is one hundred percent, and the gap between "has an annotation" and "has a test that proves the annotation works" is usually where the real risk hides.

Authorization failure rate. The rate of 403 responses in production. There is a normal baseline of legitimate access attempts that fail, and learning that baseline is the point. A spike from one user or session is a strong enumeration signal. A sustained, broad elevation usually means something is broken rather than under attack, and that distinction is worth wiring into the alerting so the on-call person knows which one they are looking at.

For leadership, fold these into the same dashboard the metrics post describes rather than building a separate one. The two views worth surfacing for access control specifically are the compliance status against PCI-DSS, SOC 2, GDPR, and HIPAA, and the access control coverage trend, since both translate cleanly into the language executives already think in.

6. Detecting and Responding to Access Control Incidents

The incident response lifecycle, identify, contain, eradicate, recover, and the lessons-learned review, along with the stakeholder communication templates, is laid out in the metrics program post. It applies to access control incidents without modification. What changes by class is what the attack looks like in your telemetry and a few response steps that are specific to authorization failures.

What Detection Looks Like

Access control attacks tend to announce themselves in three patterns, if you are watching for them.

Authorization failure patterns. A burst of 403s from a single user or session. Sequential resource ID access. Access attempts spread across resources that have no business being touched by the same account. Activity that does not match the user's normal behavior.

Anomalous access patterns. A user reaching outside their usual scope. Access at hours that are odd for that person. Geographic impossibilities, where the same account appears in two distant places within minutes. Access velocity no human could produce.

Exfiltration indicators. A large volume of retrievals in a short window. Systematic enumeration, the classic 1, 2, 3, 4 march through IDs. Bulk exports. API call volume that exceeds anything the normal application flow would generate.

The hard part is the threshold. Set it too sensitive and the alert becomes noise the team learns to ignore. Set it too loose and the slow, patient enumeration slides under it. Tune against your actual 403 baseline rather than a number from a blog post, this one included.

Response Steps That Are Specific to Access Control

Within the generic containment phase, a few moves are particular to this class. Forcing re-authentication on affected users is often more proportionate than a blanket session purge. Disabling the single vulnerable endpoint may be cleaner than pulling the whole service. And early on, the scoping question that matters most is whose data was reachable, which means mapping the enumerated identifiers back to resource owners so the notification scope is accurate rather than guessed.

In the recovery and lessons-learned phases, the access-control-specific task is to go looking for the same mistake elsewhere. An IDOR is rarely unique. If one endpoint skipped the ownership check, the pattern that produced it almost certainly produced others. Sweep the related controllers and the shared authorization helpers before you call it closed, and feed whatever you find back into the custom Semgrep rules so the gate catches the next one automatically.

7. Organizational Considerations

Architecture lives inside an organization, and the human and process pieces decide whether the technical controls survive contact with a deadline.

Security Champions, Applied to Access Control

The champions program, who they are, how they are selected, the time allocation, and the central support model, is described in the metrics program post. For access control specifically, the champion's job is to be the person on the team who notices when a new endpoint touches user-specific data and asks where the ownership check is. They review changes to the authorization service before those changes merge, and they confirm that authorization tests exist rather than assuming they do. That is a narrow, concrete remit, which is exactly why it works.

Authorization Governance

Some authorization changes are too consequential to slip through normal review. A new authorization model, a change to a role definition, or any modification to tenant isolation logic should require a deliberate security review that considers the threat model and the compliance implications, not just whether the code compiles.

Exceptions need a real process. A team that wants to deviate from an authorization requirement should have to write down the business justification, the compensating controls, and an expiry date, and get sign-off one level above the normal approver. Track the exceptions as a number. If they start piling up, the requirement is probably unrealistic or the tooling is too painful, and that is useful to know.

Access reviews close the loop. Periodically check that role definitions and permission assignments still match what people actually do. Strip permissions no one uses. The role someone needed for a project two years ago is the role an attacker inherits when that account is compromised.

Third-Party and Vendor Risk

Authorization risk does not stop at code you wrote. When you adopt an authentication or authorization library, look at whether its defaults are secure, whether it is actively maintained, and whether it has a history of access control CVEs. When a third party integrates with your system, be explicit about what it can reach and how you would verify it honors your access rules. And for the SaaS tools your own organization depends on, their tenant isolation is your tenant isolation, so read the SOC 2 report rather than taking the sales deck's word for it. Put these expectations into vendor assessments and contracts where it matters.

Talking About Access Control to Different Rooms

The same finding needs different framing depending on who is listening, and getting this wrong is how good security work fails to land. Developers want the pattern and the fix, grounded in Spring Security and the authorization model they already use, not abstract threat language. Product managers want the user impact and the honest trade-off on velocity, plus a reason authorization is worth the extra development time. Engineering leadership responds to the technical-debt framing and the argument that authorization investment now means fewer emergency patches later. Executives want business impact, regulatory exposure, and a comparison to what happened to a peer who got it wrong. Auditors want documentation, evidence, and clean mappings between requirements and controls. The underlying program does not change between these conversations. Only the language does.

Architecture Decision Records

Write down the access control decisions while the reasoning is fresh. The ones worth an ADR are predictable: why RBAC or ABAC or a hybrid, and what the rejected alternatives cost. How tenant data is separated, what prevents cross-tenant access, and what would detect an isolation failure. Where authorization decisions are enforced and why at that layer. How authorization claims are carried, how long tokens live, and how revocation works.

ADRs are not bureaucracy for its own sake. They are the institutional memory that lets the next engineer understand why the system is shaped the way it is, they shorten onboarding, and they give an auditor concrete evidence that the design was deliberate rather than accidental.

Wrapping Part 3

Access control is not only a coding problem, and treating it like one is how it ends up at the top of the OWASP list year after year. Authorization has to be right in every endpoint, for every resource, on every path, and the size of that surface is the whole challenge.

The architect's job is to stop thinking about individual findings and start building a system with three properties. Failures should be hard to create, through secure defaults, guardrails, and training that uses your own code. They should be caught quickly when they happen anyway, through custom SAST rules, authorization-focused testing, and monitoring tuned to your real baseline. And they should be closed fast, through the SLA, ownership, and measurement machinery that the metrics program post covers in full.

That is the division of labor across this series. Parts 1 and 2 are the developer's view: how IDOR and vertical escalation actually work, and how to write the ownership checks, the Spring Security annotations, and the authorization services that prevent them. Part 3 is the architect's view: the threat model, the prioritization, the compliance lines, and the architectural controls that keep those practices consistent across the whole organization rather than dependent on whichever developer happened to remember.

Access control findings are going to keep appearing in assessments. That is not a sign of failure, it is the nature of the category. The question that actually matters is whether you find them before an attacker does, and how fast you move when one surfaces. Building that takes the technical foundation from the first two parts and the program around it from this one. The program-level scaffolding is shared across every vulnerability class, which is why it lives in its own post. What you have read here is the part that only access control needs.