Web Vulnerabilities 101 (Part 2): Access Control, Authentication and Configuration — Where Large Systems Break

The flaws in part one share one trait: they are coding mistakes, and scanners usually find them. This article covers a different family. Here the code runs exactly as designed — the design and the configuration are what is wrong. No automated tool knows that someone in accounting should not be able to open the CEO's payroll record. Only you know that.

This is why OWASP Top 10:2025 keeps Broken Access Control at number one, with 40 CWEs, more than 1.8 million occurrences and 32,654 CVEs in the contributed data, while Security Misconfiguration jumped from fifth to second place with over 719,000 occurrences.

1. Broken Access Control (A01): champion for several editions running

A few symptoms that are uncomfortably familiar:

• IDOR — changing an identifier from invoice 1042 to 1043 reveals someone else's invoice, because the API checks "are you logged in" but forgets "is this record yours".
• Force browsing — typing /admin/dashboard directly works, because the admin page was merely hidden from the menu rather than protected on the server.
• Authorisation implemented in the frontend — the delete button is hidden by JavaScript, yet the DELETE endpoint happily accepts a request sent with curl. OWASP documents exactly this scenario.
• Privilege escalation by tampering with a JWT or cookie, overly permissive CORS letting untrusted origins call the API, and APIs missing checks on POST, PUT and DELETE.

How to prevent it

The foundation is deny by default: everything is closed, and only explicitly listed capabilities are opened. Authorisation checks must live in server-side code the attacker cannot modify. Build the mechanism once and reuse it across the application instead of letting every controller invent its own, because the hole is always in the endpoint someone forgot. Models should enforce record ownership, not just roles. Sessions must be invalidated server-side on logout; JWTs should be short-lived with refresh tokens so access can actually be revoked.

One high-value practice most teams skip: write integration tests for authorisation. Every sensitive endpoint gets a test asserting that user A cannot touch user B's data. QA can own this, and it catches far more than an annual penetration test.

2. CSRF: abusing the victim's own session

A user is logged into their bank in one tab and opens a malicious page in another. That page silently issues a transfer request, and the browser attaches the session cookie automatically. The server sees a perfectly valid request and executes it.

Prevention: set SameSite to Lax or Strict on session cookies (a browser default now, but declare it explicitly anyway); apply anti-CSRF tokens using the synchroniser token pattern on state-changing forms; verify the Origin or Referer header on sensitive endpoints; and never use GET for actions that change data.

3. Authentication Failures (A07)

The dominant risk today is not someone cracking your password but credential stuffing: attackers take millions of email and password pairs leaked elsewhere and replay them against your login. A common variant sprays incremental guesses such as Password1!, Password2!. Add to that session fixation, session identifiers exposed in URLs, sessions that survive logout, and password recovery based on knowledge questions — which OWASP considers impossible to make safe.

How to prevent it

Enable multi-factor authentication wherever possible, especially for administrators. Never ship default credentials. Check new passwords against common weak lists and known-breached credential lists. Following NIST 800-63B, do not force periodic password rotation — require a reset only when you suspect compromise, because forced rotation makes passwords weaker. Store passwords with a purpose-built hash such as Argon2 or bcrypt with a salt. Issue a fresh session ID after successful login, keep it in a cookie marked Secure, HttpOnly and SameSite, and enforce both idle and absolute timeouts. Return identical messages for every failed login to prevent account enumeration. For JWTs, validate aud, iss, exp and the signing algorithm. Where possible, buy a hardened identity solution rather than writing your own.

4. Cryptographic Failures (A04)

This category is rarely about broken algorithms and almost always about misuse: sensitive data transmitted or stored in the clear, legacy algorithms such as MD5 or SHA-1 used for passwords, home-grown encryption schemes, or careless key management.

Prevention: require TLS on every connection including internal ones and enable HSTS; classify data so you know what genuinely needs encryption at rest; use standard libraries with authenticated encryption modes instead of assembling primitives yourself; keep keys and secrets in a KMS or secret manager rather than configuration files in the repository; and do not store what you do not need — data that does not exist cannot be stolen.

5. Security Misconfiguration (A02): the fastest climber

The reason is straightforward: more and more system behaviour is decided by configuration rather than code. Classic scenarios include sample applications and admin consoles left on production with default passwords, directory listing still enabled, detailed stack traces returned straight to the browser exposing component versions, and cloud storage buckets left open to the Internet.

Prevention: build a repeatable hardening process automated through Infrastructure as Code, so a new environment always comes up equally locked down; keep dev, QA and production configured identically but with different credentials; remove every unused feature, port, account and sample document; ship the full set of security headers such as Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options and Referrer-Policy; intercept verbose error messages with a central handler; prefer identity federation and short-lived credentials over static keys embedded in code or pipelines; and add an automated step that verifies configuration across all environments.

6. Software Supply Chain Failures (A03): the new entry the community fears most

Exactly 50% of respondents in the OWASP community survey ranked this category first. It expands the old "outdated components" risk to the whole ecosystem: direct and transitive dependencies, IDEs and extensions, registries, images, build and distribution systems. Notably it has the fewest CVEs of any category but the highest average exploit and impact scores — rare, but devastating.

Prevention: generate and manage an SBOM for the entire product; track transitive dependencies, not just direct ones; remove libraries you no longer use; scan continuously with tools such as OWASP Dependency-Track or Dependency-Check and follow CVE, NVD and OSV feeds; pull artefacts only from trusted, signed sources; enforce least privilege and separation of duty in CI/CD so that no single person can push code to production without a second pair of eyes; and remember the build pipeline needs at least as much protection as the systems it deploys.

7. Logging & Alerting (A09) and Mishandling of Exceptional Conditions (A10)

These two are the most neglected because they cause no direct damage — they simply leave you unaware that you are being attacked. The 2025 edition renamed A09 to Logging and Alerting to make the point: excellent logs with no alerting are close to worthless.

Make sure every successful and failed login, every access denial and every high-value transaction is recorded with enough context to investigate. Logs should be machine-readable, shipped off the application host, protected with integrity controls against tampering, and must never contain passwords, tokens or personal data. Pair them with sensible alert thresholds and response playbooks, because a flood of false positives guarantees the real alert gets missed.

A10 is brand new in 2025 and gathers 24 CWEs about mishandled errors: sensitive information in error messages, missing parameters left unhandled, and above all failing open — the system defaulting to "allow" when something goes wrong. The rule is fail closed: if the authentication service does not respond, deny. Catch errors where they occur, keep a global exception handler as a safety net, roll back partial transactions completely, and monitor repeated error patterns, which are often the fingerprint of an ongoing probe.

A 30 / 60 / 90 day roadmap for teams already in production

First 30 days — cheap, high-impact work: rotate every default credential, enable MFA for admin accounts, disable directory listing and stack traces in production, add security headers, turn on dependency scanning in CI, and review public access on storage buckets.

Next 30 days — the parts that need code changes: audit every endpoint and add record-ownership checks, write authorisation integration tests for sensitive endpoints, standardise authentication and session management, and move secrets into a secret manager.

By day 90 — build lasting capability: automate SBOM generation, harden infrastructure through code, centralise logs with alert rules and playbooks, and run a tabletop incident exercise to test the response process.

Conclusion

If part one was a developer story, part two belongs to the whole team: architects decide the authorisation model, DevOps decides the configuration, QA decides what gets tested, and operations decides whether you notice an incident in five minutes or five months. Application security is not a checkbox before go-live; it is a habit repeated every sprint.

References

• OWASP Top 10:2025 — owasp.org/Top10/2025
• OWASP Cheat Sheet Series — cheatsheetseries.owasp.org
• PortSwigger Web Security Academy — portswigger.net/web-security
• NIST SP 800-63B Digital Identity Guidelines — pages.nist.gov/800-63-3