OWASP Top 10 in practice: what each risk means and how DAST helps

OWASP Top 10 - Most critical web application security risks

The OWASP Top 10 is a standard list of the most critical security risks to web applications. Here's what each category means in practice—and how dynamic security testing (DAST) helps you find and fix them.

What is the OWASP Top 10?

The OWASP Top 10 is a consensus list from the Open Web Application Security Project (OWASP) of the most critical security risks to web applications—used by developers, auditors, and security teams to prioritize what to test and fix.

The OWASP Top 10 2025 are:

  • A01:2025 – Broken Access Control
  • A02:2025 – Security Misconfiguration
  • A03:2025 – Software Supply Chain Failures
  • A04:2025 – Cryptographic Failures
  • A05:2025 – Injection
  • A06:2025 – Insecure Design
  • A07:2025 – Authentication Failures
  • A08:2025 – Software or Data Integrity Failures
  • A09:2025 – Security Logging and Alerting Failures
  • A10:2025 – Mishandling of Exceptional Conditions

The list is updated every few years; it's a focused set of categories that show up again and again in real applications. Many DAST tools, including Scryn (which uses OWASP ZAP under the hood), are built to look for issues that fall into these categories. Below we walk through each of the ten, what they mean in practice, and how DAST can help.

A01:2025 – Broken Access Control

Broken access control means users can do things they shouldn't—for example, viewing another user's data by changing an ID in the URL, accessing admin pages without being an admin, or bypassing checks by tampering with parameters. In practice, this often comes down to the app trusting the client (e.g. "user_id" in a request) instead of enforcing permissions on the server.

DAST can help by probing URLs and parameters (e.g. different IDs, paths like /admin) and checking whether the server returns data or actions that should be restricted. It can't prove that access control is correct everywhere, but it can find obvious bypasses and missing checks. Scryn can test both public and authenticated areas when you configure login, so you can scan pages that should only be available to certain roles.

A02:2025 – Security Misconfiguration

Security misconfiguration includes default credentials, unnecessary features enabled, missing or weak security headers (e.g. Content-Security-Policy, HSTS, X-Frame-Options), verbose error pages that leak stack traces or paths, and open debug or admin interfaces. These are often easy to fix once you know they exist.

DAST is excellent at finding misconfiguration. Passive and active scans check response headers, error pages, and common paths (e.g. /debug, /console) and report missing or unsafe settings. Scryn surfaces these in its reports so you can tighten configuration and reduce your attack surface quickly.

A03:2025 – Software Supply Chain Failures

This category covers breakdowns in building, distributing, or updating software—vulnerable or malicious third-party code, unpatched dependencies, weak CI/CD security, or use of components from untrusted sources. It evolved from the older "Vulnerable and Outdated Components" to include the full supply chain (e.g. build pipelines, artifact signing, SBOMs).

DAST can sometimes infer technology and versions from headers, cookies, or HTML and flag known issues. For thorough coverage you need dependency scanning, SBOM tooling, and secure build pipelines. Use DAST as a runtime check; pair it with SCA, dependency management, and supply-chain hardening for A03.

A04:2025 – Cryptographic Failures

This category covers failures related to encryption and hashing: data transmitted or stored without encryption, weak algorithms, hardcoded or default crypto keys, or sensitive data exposed in URLs or logs. Classic examples are sending passwords over HTTP, using outdated TLS versions, or storing passwords with a weak hash.

DAST can detect some of this: for example, whether the site is served over HTTPS, whether security headers are present, and whether sensitive data appears in responses or error messages. It won't see how you hash passwords in the database or how you manage keys—those need code review and architecture review. Use DAST for transport and response exposure; combine with other practices for the rest.

A05:2025 – Injection

Injection is when untrusted input (from a form, URL, header, or API parameter) is used in a way that changes the meaning of a command or query—SQL injection, command injection, LDAP injection, and similar. The attacker sends crafted input so the application executes something it didn't intend (e.g. running a SQL query that dumps data).

DAST is very well suited to finding injection. Tools send a large set of probe payloads to inputs and analyze responses for signs that injection worked (e.g. database errors, changed behavior, or data that shouldn't be visible). Scryn runs active scans that include injection tests against your URLs and parameters, and reports findings with risk levels and guidance. This is one of the areas where DAST gives the most direct value.

A06:2025 – Insecure Design

Insecure design refers to security flaws that come from design decisions rather than implementation bugs—missing threat modeling, weak business logic (e.g. "one-click" privilege escalation), or flows that assume users won't abuse the system. Fixing these usually requires changing how the feature works, not just patching code.

DAST can't tell you that your design is insecure by itself; it tests behavior. It may still find symptoms—for example, a multi-step flow that can be bypassed by calling an endpoint directly—so running DAST on realistic workflows can surface some design-level issues. For full coverage, combine DAST with threat modeling and manual testing of business logic.

A07:2025 – Authentication Failures

Authentication failures include weak passwords, no multi-factor authentication, session fixation, predictable session IDs, or sessions that don't expire properly. It also covers credential stuffing and brute force when the app doesn't limit or lock after failed attempts.

DAST can test login flows: it can check for lockout mechanisms, session handling (cookies, tokens), and whether protected URLs are actually protected. When you configure authentication in Scryn, the scanner can reach pages behind login and verify that unauthenticated requests are denied. So DAST helps you validate that auth and session behavior are correct from the outside; password policy and MFA rollout are still policy and design decisions.

A08:2025 – Software or Data Integrity Failures

This category covers trust in code and data—for example, deserializing untrusted data without verification, using libraries from untrusted sources, or updating software without integrity checks (e.g. unsigned updates). CI/CD pipelines that don't verify artifacts also fall here.

DAST doesn't directly assess integrity of your build pipeline or dependencies; that's handled by supply-chain and build security. DAST can still help by testing the running app for behavior that might indicate integrity issues (e.g. unexpected deserialization or plugin behavior) if such behavior is exposed via HTTP. Treat this category mainly with secure design, signing, and dependency/artifact verification; use DAST where the app exposes relevant endpoints.

A09:2025 – Security Logging and Alerting Failures

Logging and alerting failures mean missing or insufficient logging of security-relevant events (logins, access to sensitive data, failures), or no effective monitoring and alerting. When an incident happens, lack of logs makes detection and investigation much harder.

DAST doesn't implement logging for you; it tests the app from the outside. It can still trigger events (e.g. failed logins, access attempts) that you can use to verify your logging and alerts are working—so run a scan and then check that your SIEM or logs show the expected activity. Use DAST as a way to generate traffic and validate that your monitoring sees it.

A10:2025 – Mishandling of Exceptional Conditions

Mishandling of exceptional conditions is a new category in 2025. It covers improper error handling, failing open (e.g. allowing access when a check fails), sensitive information in error messages, and missing or inconsistent handling of unusual situations—missing parameters, insufficient privileges, or resource exhaustion. These can lead to information leakage, state corruption, or denial of service.

DAST can help by triggering errors and unusual conditions and checking whether the app responds safely: do error pages leak stack traces or paths? Does the app fail open or leave transactions in a bad state? Scryn and similar tools report verbose error messages and missing custom error pages as findings. Fix by centralizing error handling, failing closed, and avoiding sensitive data in user-facing errors.

Note: Server-Side Request Forgery (SSRF) was in the 2021 Top 10 but is not in the 2025 list. It's still a serious risk when your app fetches user-supplied URLs. DAST can probe for SSRF where the app accepts URLs or hostnames—enable or tune those checks in Scryn when testing such features.

Cross-site scripting (XSS) and the Top 10

Cross-site scripting (XSS) is a form of injection into HTML/JavaScript context, so it falls under A05:2025 Injection. XSS is when user input is reflected in the response in a way that allows an attacker to run script in a victim's browser—often used to steal sessions or deface pages. DAST is very good at finding XSS: it sends script payloads and checks whether they appear in the response in an executable way. Scryn's active scans include XSS checks, and findings are reported with the affected URL and parameter so you can fix them.

Using the Top 10 in practice

The OWASP Top 10 is a useful lens for prioritization and communication. In practice:

  • Run DAST regularly so you catch injection, misconfiguration, and many access-control and auth issues early. Scryn supports on-demand and scheduled scans so you can maintain a baseline.
  • Combine with other practices: use dependency and supply-chain tooling for A03, threat modeling and code review for design and integrity (A06, A08), and logging/alerting for A09. DAST is strongest for runtime behavior that shows up in HTTP.
  • Fix and re-scan. Treat findings as a backlog: fix high-risk items first, mark false positives so they don't distract you, and run another scan to confirm issues are resolved and nothing new appeared.

Wrapping up

The OWASP Top 10 gives you a shared vocabulary and a clear set of targets. DAST doesn't cover every category equally—it excels at injection, misconfiguration, and many authentication and access-control issues that manifest in the running app. For the rest, pair DAST with secure design, dependency management, and good logging and monitoring. Scryn is built to help you tackle the Top 10 where it matters most: by scanning your live app or API and reporting what an attacker would see, so you can fix it before they do.