The OWASP Top 10:2025, and Where Safeey Has You Covered

The OWASP Top 10 is the reference standard for the most critical web application security risks — a prioritised list, rebuilt every few years from real-world data, that most security programs use as their starting point. The latest edition, OWASP Top 10:2025, is the first update since 2021, and it reflects a clear shift: away from isolated coding bugs and toward systemic risks across configuration, dependencies, and operations.

So where does Safeey fit? Safeey checks your security posture from two angles — the web scanner looks at your live site from the outside (dynamic testing), and safeey-cli reads your source code from the inside (static testing). Between them they cover a large share of the Top 10. But we're going to be honest about this: some categories are exactly what automated scanning is built for, and some genuinely require human judgement. Knowing which is which is the whole point.

Here's the 2025 list, and where Safeey has you covered.

A01 — Broken Access Control

The #1 risk: users or attackers reaching data and actions they shouldn't. In 2025, Server-Side Request Forgery (SSRF) was folded into this category.

How Safeey helps: The web scanner probes for reachable admin panels, unauthenticated API endpoints (its API-discovery stage tests the endpoints your own JavaScript calls, without credentials, to see what answers), open redirects, and permissive CORS. These are the outward symptoms of broken access control.

Where you still need a human: Deep, per-user authorization logic — "can user A read user B's records?" — depends on your business rules and usually needs manual testing. Safeey flags the exposed doors; it can't know every rule about who's allowed through them.

A02 — Security Misconfiguration

Up from #5 to #2: exposed default accounts, unnecessary services, missing security headers, verbose errors, and open cloud storage.

How Safeey helps: This is Safeey's home turf. The web scanner checks your security headers (CSP, HSTS, X-Frame-Options and more), hunts for exposed files (.env, .git, backups, config), tests for default credentials and directory listings, and flags debug modes and information leaks. This is the single category Safeey covers most thoroughly — and it's now the #2 risk in the world.

A03 — Software Supply Chain Failures

A new, broadened category (expanding the old "Vulnerable and Outdated Components") covering compromised dependencies, build systems, and distribution — voted the top concern by the community.

How Safeey helps: safeey-cli scans your package.json for known-vulnerable and unpinned dependencies — the most common and exploitable slice of this category.

Where it's evolving: Full supply-chain coverage (deep CVE data, build-pipeline integrity) is broader than any single dependency check. Safeey covers the dependency layer; treat build and distribution security as a complementary practice.

A04 — Cryptographic Failures

Weak or misused cryptography leading to sensitive-data exposure.

How Safeey helps: The web scanner verifies HTTPS, inspects your TLS certificate and configuration, checks HSTS (including preload eligibility), and flags insecure transport and mixed content. safeey-cli catches weak hashing (MD5/SHA-1) and disabled TLS verification (rejectUnauthorized: false) in code. Strong coverage on the detectable parts.

A05 — Injection

SQL injection, cross-site scripting (XSS), command injection, and friends. Lower-ranked than before, but still heavily exploited.

How Safeey helps: safeey-cli detects the classic injection shapes in code — SQL built by string interpolation, innerHTML/dangerouslySetInnerHTML fed dynamic input, command injection via child_process, and eval-style execution. The web scanner adds reflected-input probing from the outside. Solid code-level coverage of one of the oldest and most damaging categories.

A06 — Insecure Design

Flaws baked into the architecture itself — where security was never designed in.

Where Safeey stops, honestly: This one is mostly not something any automated scanner can find, and we won't pretend otherwise. Insecure design is about missing threat models, flawed trust boundaries, and business-logic gaps — the kind of thing a tool can't infer from code or traffic. Safeey may catch a downstream symptom, but this category is a genuine call for human review and threat modelling. A good scanner tells you where it can't help; here's one of those places.

A07 — Authentication Failures

Weak passwords, missing MFA, session fixation, insecure credential storage.

How Safeey helps: The web scanner checks the parts that are externally visible — insecure session-cookie flags (HttpOnly, Secure, SameSite), signals of account enumeration, exposed auth endpoints, and the transport protecting credentials. safeey-cli flags hardcoded credentials in code.

Where you still need a human: Whether you enforce MFA, how you store password hashes, and your session lifecycle are design decisions a scan can partially observe but not fully validate.

A08 — Software or Data Integrity Failures

Trusting code, updates, or data without verifying integrity — insecure deserialization, unsigned updates, tampered pipelines.

Where Safeey is limited: Coverage here is partial. safeey-cli catches related issues like hardcoded secrets and some unsafe patterns, and the supply-chain checks overlap — but verifying update signing and deserialization safety across your stack is largely a process and review concern. We'd rather tell you that than overstate it.

A09 — Security Logging and Alerting Failures

Renamed in 2025 to emphasise alerting: gaps in monitoring that delay incident detection.

Where Safeey stops, honestly: This category is about what you're not doing — logging and alerting you failed to set up — and that's fundamentally invisible to both an external scanner and a code scanner. No automated tool can meaningfully tell you your alerting is inadequate. This is an operations and architecture responsibility, full stop.

A10 — Mishandling of Exceptional Conditions

A new category: incorrect error handling — failing open instead of closed, leaking stack traces, continuing in an undefined state.

How Safeey helps: The web scanner detects the externally-visible symptoms — verbose error pages, exposed stack traces, and debug modes that leak internal detail to anyone who triggers an error. Those information leaks are exactly what an attacker uses for reconnaissance.

Where you still need a human: The deeper logic — does your code fail closed under an unexpected exception? — is a code-review and testing matter.

The honest scorecard

Put it together and a clear picture emerges. Safeey provides strong, automated coverage of the categories that are automatable — Security Misconfiguration (A02), Cryptographic Failures (A04), and Injection (A05) — plus meaningful coverage of the externally-visible parts of Broken Access Control (A01), Software Supply Chain (A03), Authentication (A07), and Exceptional Conditions (A10).

And it's candid about the rest: Insecure Design (A06), Data Integrity (A08), and Logging & Alerting (A09) are categories where human review, threat modelling, and operational discipline do the heavy lifting. No scanner replaces those — and any tool that claims to is selling you a false sense of security.

That's the right way to use the OWASP Top 10, and Safeey with it: as the fast, automated first pass that catches the large majority of real, exploitable issues — the exposed files, the missing headers, the injectable queries, the leaked secrets, the vulnerable dependencies — so your human review time goes to the design and process questions that genuinely need it.

Cover your automatable risk in minutes

Scan your live site and your code against the categories a tool can catch:

npm install -g safeey-cli && safeey scan ./

And point a Safeey scan at your live URL. Between them you'll close out the bulk of the OWASP Top 10:2025 that automation can reach — and know exactly which categories to hand to a human.