OWASP Top 10 (2024 update) explained — and what CyberScore actually checks

Before getting into the per-category detail, a short orientation for readers who last looked at the list in 2017. The 2021 release was not a cosmetic renumbering; three categories are new, three were renamed, and the ranking shifted in ways that reflect a decade of shifting attacker focus.

• New in 2021: A04 Insecure Design, A08 Software and Data Integrity Failures, A10 SSRF. The first two are explicit acknowledgements that "the bug is in the implementation" is no longer a complete model — design gaps and supply-chain trust gaps deserve their own categories.
• Renamed: what was "Sensitive Data Exposure" is now A02 Cryptographic Failures (root cause, not symptom); "Broken Authentication" became A07 Identification and Authentication Failures; XSS, which had its own slot in 2017, is folded into A03 Injection.
• Moved up: Broken Access Control jumped from #5 in 2017 to #1 in 2021. OWASP's contributor data showed it was both the most common and most impactful category — the API era made authorisation flaws particularly easy to exploit at scale.
• Quietly demoted: Classical SQL injection, the category that defined 2010s web security, no longer has its own slot. ORMs, prepared statements and a generation of training have reduced its prevalence, though not eliminated it.

Access control fails when a user can read, modify, or delete an object that they should not be allowed to touch. The classic web case is changing /account/123 to /account/124 and getting somebody else's data. In APIs the same flaw is called BOLA (Broken Object Level Authorization) and tops the OWASP API Security Top 10.

Real-world example. The Equifax 2017 breach combined several failures but the post-mortem from the U.S. House Oversight Committee documented access-control gaps that allowed lateral movement once initial access was achieved. More recently, the publicly reported Optus 2022 case is the canonical API access-control failure — an endpoint that accepted incrementing customer identifiers without verifying ownership.

CyberScore detection. 🟡 Signal only. We detect public admin paths (/admin, /wp-admin, common variants), exposed /api/users patterns, and BOLA-shaped endpoints when we can parse a public Swagger or OpenAPI document. We do not actively probe access controls — that is the territory of an authenticated DAST or a manual pentest. See our BOLA explainer for the API-side detail.

Previously called "Sensitive Data Exposure". Renamed in 2021 to focus on the root cause rather than the visible symptom: weak or missing cryptography, bad TLS configuration, deprecated protocols, data stored or transmitted in clear, weak password hashing, hardcoded keys.

Real-world example. A recurring class of incidents: companies still accepting TLS 1.0 / 1.1 connections, certificates that quietly expire on a Saturday afternoon, internal services exposed on HTTP with no redirect. The most embarrassing version is an admin interface protected by a strong password served over plain HTTP.

CyberScore detection. ✅ Detected. This is one of our strongest categories. We run a full TLS audit: weak ciphers, expired or soon-to-expire certificates, self-signed leaves on production hosts, deprecated protocols (TLS 1.0 / 1.1), missing HSTS, weak signature algorithms, mismatched certificate chains. We also flag plain-HTTP admin surfaces and missing HTTPS redirects. The email-authentication side (SPF / DKIM / DMARC) is adjacent — we cover that too, separately, in our DMARC / SPF / DKIM guide.

Untrusted input that ends up interpreted as code or as a query. SQL injection, cross-site scripting (XSS — merged into this category in 2021), OS command injection, LDAP injection, template injection. The 2021 merge of XSS into Injection raised eyebrows but is defensible: structurally they are the same failure of input-context separation.

Real-world example. SQL injection has been the textbook example since the late 1990s. ORMs and prepared statements have made it less common in modern stacks but it still appears regularly in legacy code paths, in raw-SQL escape hatches, and in NoSQL contexts where developers assume escaping is not needed. XSS remains the most common payload-driven web flaw.

CyberScore detection. ❌ Not in scope. We do not send injection payloads. Detecting injection requires actively probing inputs with malicious strings and observing the response, which is the job of an active DAST (Burp Suite, OWASP ZAP, Acunetix, AppCheck) or a manual pentester. We are passive by design and stay out of that lane. The closest thing we offer in adjacent territory is flagging exposed framework error pages or debug consoles that would reveal stack traces on successful payload delivery — useful context, not injection detection.

New category in 2021. It captures vulnerabilities that come from missing or broken security design rather than from implementation bugs — no threat modelling for a sensitive feature, a password reset flow that lets you brute-force the answer to a security question, business logic that lets you place an order with a negative quantity and get refunded.

Real-world example. A classic insecure-design case is the password-reset flow that returns a different error for "email exists" versus "email not registered", allowing user enumeration. The implementation is correct; the design leaked the wrong information.

CyberScore detection. ❌ Not in scope. No scanner detects insecure design. This is a design-review and threat-modelling discipline that lives upstream of any automated tool. The best approximation is a SAST tool in CI that flags suspicious patterns (e.g. a controller that returns different status codes for present vs absent users), plus structured threat modelling on every significant feature. Frameworks worth knowing: STRIDE for categorising threats, PASTA when you want a more rigorous business-context lens, and the OWASP Threat Modeling Cheat Sheet as a starter. None of these are CyberScore's job; we mention them because A04 is the category most commonly written off as "too abstract to act on", and it is the cheapest to start on with one half-day workshop per quarter.

The grab-bag category: defaults left in place, debug pages exposed in production, permissive CORS, missing security headers, S3 buckets public when they should be private, GraphQL introspection enabled, Swagger UI live in prod, framework error pages disclosing stack traces.

Real-world example. Capital One 2019 (also an SSRF case, see A10) involved a misconfigured WAF that allowed instance-metadata access. More mundanely, every quarter has its set of companies whose .env or .git directory was left readable on a public web root.

CyberScore detection. ✅ Detected. This is the broadest category we cover. We check security headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy), exposed .env and .git files, public S3 / GCS / Azure Blob buckets via OSINT discovery, default-credential surfaces (we flag login pages without identifying users), GraphQL introspection enabled in production, Swagger / OpenAPI live in production, common debug endpoints. This is where most of our user-visible findings come from.

Using software with known vulnerabilities: an unpatched Apache, a five-year-old jQuery, a Node.js LTS that exited support, a Drupal install pinned at a version with a critical CVE. This category is the bread and butter of CVE-based vulnerability management.

Real-world example. Equifax 2017 again — the entry vector was an unpatched Apache Struts (CVE-2017-5638) for which a fix had existed for over two months when the breach started. The component was known to be vulnerable, the patch was available, the inventory missed it.

CyberScore detection. ✅ Detected. Technology fingerprinting with version extraction, then NVD CVE matching against the detected versions. We cover server software (Apache, nginx, IIS, Node), CMS platforms (WordPress, Drupal, Joomla, Magento), JavaScript libraries (jQuery, Lodash, AngularJS, etc.), and cross-reference against CISA KEV for actively exploited vulnerabilities so the most urgent items rise to the top. See our ASM pillar guide for how this fits the broader picture.

Renamed from "Broken Authentication". Weak password policies, no rate limiting on login, session tokens that don't rotate, password reset flows that leak tokens in URLs, missing MFA on sensitive accounts, credential stuffing not blocked.

Real-world example. Credential-stuffing attacks against consumer brands are now constant background noise — Disney+, DoorDash, Dunkin' Donuts and many others have had public incidents traced to reused credentials and missing rate limits or MFA on login endpoints.

CyberScore detection. 🟡 Signal only. We detect public login pages, public password-reset flows, MFA prompts (or their absence on the visible page), CAPTCHA presence, reset tokens in URLs when surfaced by HTTP responses. We do not attempt credentials, do not test rate limits, and do not try to enumerate users. For real auth testing you need an authenticated DAST or a pentester with a budget for a few hundred credential-stuffing attempts in a controlled window.

New category in 2021, prompted by the wave of supply-chain incidents. Covers CI/CD pipelines that accept unsigned artifacts, software-update mechanisms without integrity verification, deserialisation of untrusted data, and dependencies pulled from untrusted sources without integrity pinning.

Real-world example. SolarWinds 2020 is the textbook case: a backdoor inserted into the build process of Orion software updates, signed with a legitimate certificate, distributed to thousands of customer environments including U.S. federal agencies. The integrity check happened, but on a compromised artifact.

CyberScore detection. 🟡 Signal only. We can flag CI/CD configuration files leaked publicly (a .github/workflows committed with secrets, a public Jenkins config) and exposed package registries — patterns the TruffleHog family of tools also detects. Actual supply-chain integrity (signed builds, SBOM verification, attestation chains) requires SBOM tooling — Snyk Open Source, Dependency-Track, GitHub Dependabot, or in-house SLSA-style pipelines. Not our lane.

The category nobody loves and everybody gets dinged on at audit. No authentication logs, no audit trail of privileged actions, logs that overwrite after seven days, no alerting on suspicious patterns, no central log store. The result is that when something bad happens, you do not know it happened, you do not know what was taken, and you cannot prove anything to a regulator.

Real-world example. Multiple breach post-mortems mention mean-time-to-detection measured in months. The Equifax breach went undetected for roughly 76 days. The tooling existed; the alerting did not.

CyberScore detection. ❌ Not in scope. We cannot see your logs from the outside. This category is by definition an internal concern, handled by a SIEM (Splunk, Datadog Security, Elastic Security, Sentinel, Wazuh) and by your incident-response playbook. The closest adjacent thing we provide is a scan history with timestamped findings — at least the change-events on the external surface are logged on our side, which partially helps the post-incident timeline reconstruction. But that is a small slice of what A09 actually demands.

New entry in 2021 (it had been an up-and-coming bug class for years before). SSRF happens when a server-side application fetches a remote resource using user-supplied input without validating the destination, allowing an attacker to make the server reach internal endpoints — cloud metadata services, internal admin interfaces, other services in the private network.

Real-world example. Capital One 2019, where an SSRF in a web application allowed reaching the AWS EC2 instance metadata service (IMDSv1 at the time) and exfiltrating temporary credentials for an over-privileged role, leading to the exfiltration of around 100 million customer records. A textbook combination of SSRF (A10), misconfiguration (A05) and excessive IAM permissions.

CyberScore detection. 🟡 Signal only. We flag SSRF-prone patterns in externally exposed APIs — endpoints that take URL-shaped parameters (url=, callback=, webhook=) without obvious allow-listing in the documented schema. We do not actively probe by sending payloads that would cause the server to make outbound requests. Worth noting in passing: we hardened CyberScore itself against SSRF, which matters because we make a lot of outbound requests on behalf of users — the irony of an SSRF-vulnerable scanner is not lost on us.

If you are early in building a security programme and looking at the Top 10 as a roadmap, the cheapest wins by far are A02 (Cryptographic Failures), A05 (Security Misconfiguration) and A06 (Vulnerable Components). They are externally observable, fixable without architectural changes, and represent the bulk of low-hanging exposure on a typical internet-facing footprint. That is exactly the slice CyberScore is designed to cover, and a similar slice is covered by the SMB-tier scanners we compete with (Detectify, Intruder) and by tools like Nuclei for the DIY end.

Once that baseline is clean, add a DAST. Burp Suite Community is free and will get you started on A01 (Broken Access Control), A03 (Injection) and A07 (Authentication). OWASP ZAP is the open-source alternative. Move to Burp Suite Pro once you have someone who can spend half a day a week using it.

Then add a SAST in CI. Snyk Code, SonarQube, Semgrep — they will not solve A04 (Insecure Design) but they will catch the implementation patterns most associated with it, and they sharpen the developer feedback loop on A03 and A07 as a side effect.

Then a SIEM for A09. This is the most expensive step in operator time, even with a cheap tier (Wazuh open source, or a starter Datadog Security plan), but it is also the one auditors and incident responders care about most.

For A08 (supply chain), add SBOM tooling — Snyk Open Source, GitHub Dependabot, Dependency-Track — and start signing build artifacts. SLSA Level 1 is achievable in a quarter for a small engineering team.

The OWASP Top 10 is a checklist, not a maturity model. There is no medal for covering all 10 with the same tool, and no vendor that does it well. Be realistic about where you are, pick the two or three categories that are cheapest to close this quarter, and revisit next quarter. The teams that ship the best security outcomes are usually the ones that stopped trying to buy one tool to cover everything and instead stitched together three or four tools each doing one thing well.

A frequent question, especially from teams preparing for their first audit: does covering the OWASP Top 10 mean something for ISO 27001, SOC 2, PCI DSS or NIS2? The honest answer is "indirectly, yes".

None of the major compliance frameworks require the OWASP Top 10 by name as their authoritative control set. But all of them ask for an application security programme, and OWASP is the most widely cited reference for what "adequate" looks like. ISO 27001:2022 Annex A 8.25 (Secure development lifecycle) and 8.28 (Secure coding) are both routinely satisfied with reference to OWASP. SOC 2 CC7 (System Operations) and CC8 (Change Management) expect vulnerability handling that any auditor will benchmark against OWASP-style categories. PCI DSS v4.0 requirement 6.2 explicitly calls out OWASP as an example of "industry-accepted secure coding standards".

The practical implication: if you can produce, on demand, a documented programme that maps your scanner and test outputs back to the OWASP Top 10 categories, you have a credible answer to the auditor's application security question regardless of which framework you are audited against. The mapping itself is the deliverable.