Lens 3 · Architecture against you
Lens 3
Architecture against you
Broken access control, security misconfiguration, insecure design. Three risks with a common root: architectural decisions that create risk by default.
GAP BY DESIGN
01 / 16
Module 3 · Your progress
✓
Risk ≠ vulnerability
✓
What changed and why
3
Architecture against you
4
Someone else's code
5
We can't predict everything

Lenses 1 and 2 covered the foundation — what risks are, and how the list evolved. Now we look at three risks that share an uncomfortable root: your architecture creates them by default.

02 / 16
Lens 3 · A01 — Broken access control
Permissions = capacities
A01 · Broken Access Control
Access control isn't just about data. Permissions cover data and actions — what you can see and what you can do. A permission to "read file with this function" is both at once.
Two principles define the boundary:
Least privilege — every subject gets only what it strictly needs. Separation of duties — no single subject holds the full path to a sensitive outcome.
What are the "objects" being protected? Anything electronic — database records, S3 bucket files, files on an nginx disk. There is no formal difference between a record in a database and a file in S3. It's all some electronic object with access that must be controlled.
03 / 16
Threat spotlight · Where authorization breaks
Distributed auth
Click each service to see what happens inside
IdP identity provider JWT token Service A checks roles ✓ Service B no authz check ✗ Service C caches perms ⚡ Database
↑ Click a service to inspect ↑
Checks role claims
Service A validates the JWT signature and checks role claims against its own policy. If the token says role: viewer, write operations are denied.

This is the correct pattern: verify identity + enforce authorization at every service boundary. But it's one service out of three — and the others don't follow it.
No authorization check
Service B validates the JWT signature but does not check role claims or permissions at all. Any valid token — regardless of role — gets full access.

The team assumed "if the token is valid, the user is authorized." That assumption is the vulnerability. A viewer token gives the same access as admin. This is broken access control — OWASP A01.
Caches permissions
Service C checks roles — but caches the result for 15 minutes. If a user's permissions are revoked, the cached version keeps granting access.

This creates a 15-minute window of exposure after every revocation. In incident response, that's the difference between containing a breach and losing data. Cache TTLs on authorization decisions should be seconds, not minutes.
04 / 16 · Interactive
Myth vs reality
🔑
Common assumption
"Okta / SSO solves our authorization problem"
Reality
SSO solves identity. Authorization — who can access what — happens inside each service separately. Every microservice parses the token and makes its own access-control decisions. One service checks role claims. Another doesn't. A third caches permissions and misses revocations.

"Tables have different shapes and structures — and that's why we have broken access control and security misconfiguration in first and second place."
05 / 16
Knowledge check · scenario
Knowledge check
Scenario
Your microservice authorizes requests using JWT tokens. It validates the token signature to confirm the token wasn't tampered with — but it does not check the expiration field. A token stolen two weeks ago still grants access.
Which OWASP risk does this fall under?
B — Broken Access Control. The token verification is partially implemented — the signature check works, but insufficient validation of the token's claims (expiration) means an attacker with a stolen token retains access indefinitely. This is an access control failure: the system fails to properly restrict access based on token validity. It's not misconfiguration (nothing was left at default) and not a crypto failure (the crypto itself is correct).
06 / 16 · Quiz
Lens 3 · A02 — Security Misconfiguration
Four ways configuration fails
A02 · Security Misconfiguration
The old name was "shrink-wrap code attack" — using defaults straight out of the box. Today, four categories:
1
Default configurations still in place
Default users, default permissions, default databases. Remember mysql_secure_installation? Its entire purpose is removing defaults. With hundreds of components, forcing this step has become more important, not less.
2
Unnecessary features enabled
Features you don't use can leak memory, eat resources, or expose attack surface — leading to application-level denial of service, or simply paying for resources you didn't need.
3
Backward compatibility / legacy support
Maintaining backward compatibility sometimes forces insecure configurations. Launching a tool with Windows XP compatibility, for instance, can raise a vulnerable situation. Legacy support is a security cost.
4
Missing protective flags
Cookie flags like HttpOnly and Secure are not set by default. Missing them means JavaScript can read your cookies and cookies travel over unencrypted connections. The absence of a flag is itself a misconfiguration.
Champion's takeaway
Configuration drift is the silent killer. Schedule quarterly config audits — not because something broke, but because defaults change with every update.
07 / 16
Lens 3 · The decisive fix
Cookie flags
The fix you can ship today
✗ Default (insecure)
Set-Cookie: session=abc123 // no flags // JS can read it // sent over HTTP too
✓ Hardened
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict; Path=/
The decisive fix: Add HttpOnly (prevents JS access) and Secure (HTTPS only). These two flags neutralize the most common cookie-theft vectors.
By default, there is no HttpOnly, no Secure flag in the headers. Absence leads to potential data leakage.
08 / 16
Lens 3 · What secure defaults look like
Removing defaults
mysql_secure_installation
secure installation
This command exists because defaults are insecure by design. Every component you install comes with its own set of defaults that need hardening.
09 / 16
Knowledge check · scenario
Knowledge check
Scenario
Your team stores refresh tokens in secure, HttpOnly cookies. But access tokens are stored in localStorage — accessible to any JavaScript running on the page.
Where's the problem?
B — Access tokens should also be in secure cookies. localStorage is accessible to any JavaScript on the page — including injected scripts from XSS attacks. A short-lived token in localStorage is still stealable during its lifetime. The same HttpOnly + Secure protections applied to refresh tokens should apply to access tokens. "Short-lived" is a mitigation, not a solution.
10 / 16 · Quiz
Lens 3 · A06 — Insecure Design
Insecure Design
A06 · Under pressure, checks get skipped
Key principle
"Being under pressure, we didn't gather the requirements and environmental conditions properly. We didn't consider them in the design phase."
Insecure design isn't about missing a single check. It's about the design phase — when teams under delivery pressure skip gathering security requirements, environmental conditions, and boundary analysis altogether. The rank dropped from #4 to #6, but the number of CVEs hasn't decreased. The risk is as real as ever.
Compare with decisions where teams do internalize risk: adding elasticity for load, using a VM scale set instead of a single VM. When the team is aware of consequences, they do preliminary checks. Insecure design is what happens when those checks aren't done.
Pattern
Insecure design isn't a code bug — it's a requirements gap. The fix happens in sprint planning, not in code review.
11 / 16
Lens 3 · Why it happens
Running from a dog
The analogy that explains A06
🐕THREAT CHASING 🏃YOU CAN'T OUTRUN DESIGNthe fence
1
"When you're crossing the road, do you check for cars?"
Of course. You look both ways. You have the time and awareness to evaluate risk before stepping off the curb.
2
"Do you always have the time to check?"
Under normal conditions — yes. The background risk (cars) is always there, but you've internalized the check. It's automatic.
3
"When you run from a dog, you will not check."
When the immediate risk feels survival-level, the background risk gets ignored. You just cross. Engineering teams running from a delivery deadline behave exactly like someone running from a dog — they skip the check.
12 / 16
Knowledge check · classify
Knowledge check
Scenario
A team under deadline pressure pushes a new payment feature to production. They skip the security review — "we'll do it next sprint." The feature has no rate limiting, no input validation on the amount field, and no fraud-detection hooks.
This is primarily an example of:
D — Insecure Design. The individual missing controls (validation, rate limiting, fraud detection) look like bugs or misconfigurations — but the root cause is deeper. The team never gathered security requirements during the design phase. Under deadline pressure, they skipped the check entirely. That's the dog analogy in action: the immediate threat (deadline) made the background risk (security) invisible.
13 / 16 · Quiz
Lens 3 · The picture
Auth ✓ svc-users Auth ✓ svc-orders Auth ✓ svc-billing Auth ✗ svc-reports token token token token One missed check. That's all it takes. DISTRIBUTED AUTHORIZATION

Every service makes its own authorization decision. Three out of four get it right. But the attacker only needs the one that doesn't.

14 / 16
Lens 3 · What we covered
Lens 3 complete
Architecture against you
A01 — Broken Access Control: distributed authorization means every service makes its own access decisions. Permissions = data + actions. One missed check is enough.
A02 — Security Misconfiguration: defaults are insecure by design. Four categories: default configs, unnecessary features, backward compatibility, missing flags. Cookie flags are the lowest-hanging fruit.
A06 — Insecure Design: under deadline pressure, security checks get skipped entirely. The root cause isn't laziness — it's the dog analogy. When the immediate threat dominates, background risk becomes invisible.
Your score: calculating...
Next: Lens 4 — supply chain, cryptographic failures, and data integrity. Three risks connected by trust in code you didn't write.
15 / 16
Lens 3 · Done
Lens 3 complete
Architecture creates risk by default. Your job is to make it explicit.
Three risks. One root: the decisions made (or not made) at the architecture level echo through every service, every config, every sprint.
16 / 16