Owasp Top 10

OWASP® Top 10 — Skill Entry

This SKILL.md is the entrypoint for the OWASP Top 10 skill.

The skill encodes the OWASP Top 10 for Web Applications (2025) as structured, machine-readable references that an agent can query to identify, assess, and remediate web application security risks.

Normative references (Web Top 10)

1. 00 Vulnerability Index 2. 01 Broken Access Control 3. 02 Security Misconfiguration 4. 03 Software Supply Chain Failures 5. 04 Cryptographic Failures 6. 05 Injection 7. 06 Insecure Design 8. 07 Authentication Failures 9. 08 Software or Data Integrity Failures 10. 09 Security Logging and Alerting Failures 11. 10 Mishandling of Exceptional Conditions

Skill layout

• SKILL.md — this file (skill entrypoint).
• references/ — the Web Top 10 normative documents.
• 00-vulnerability-index.md — index of all vulnerability identifiers, categories, and cross-references.
• 01 through 10 — one document per vulnerability aligned with OWASP Web Application Security numbering.

Third-Party Attribution

Copyright © OWASP Foundation. OWASP® Top 10 (2025) content is derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Source: <https://owasp.org/Top10/2025/> Modifications: Vulnerability descriptions restructured into agent-consumable reference documents with added detection and remediation guidance. OWASP® is a registered trademark of the OWASP Foundation. Use does not imply endorsement.

00 Vulnerability Index

This document provides the index for the OWASP Web Application Security Top 10 vulnerabilities. Each entry includes its identifier, title, and primary category.

Vulnerability catalog

Cross-reference matrix

Each vulnerability document follows a consistent structure:

1. Description — what the vulnerability is and how it manifests in web applications. 2. Risk — concrete consequences of exploitation and business impact. 3. Vulnerability checklist — indicators that the application is exposed. 4. Prevention controls — defensive measures and rectification steps. 5. Example attack scenarios — realistic exploitation narratives. 6. Detection guidance — signals and methods to identify exposure. 7. Remediation — immediate and long-term actions to contain and resolve.

Category groupings

Access Control

• A01:2025 Broken Access Control

Configuration Management

• A02:2025 Security Misconfiguration

Supply Chain

• A03:2025 Software Supply Chain Failures

Cryptography

• A04:2025 Cryptographic Failures

Input Validation

• A05:2025 Injection

Architecture and Design

• A06:2025 Insecure Design

Authentication

• A07:2025 Authentication Failures

Data Integrity

• A08:2025 Software or Data Integrity Failures

Logging and Monitoring

• A09:2025 Security Logging and Alerting Failures

Error Handling

• A10:2025 Mishandling of Exceptional Conditions

---

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Modifications: Restructured into agent-consumable reference format with added detection and remediation guidance.

01 Broken Access Control

Identifier: A01:2025 Category: Access Control

Description

Broken access control occurs when an application fails to enforce policies that prevent users from acting outside their intended permissions. This vulnerability allows unauthorized information disclosure, modification or destruction of data, or performing business functions beyond the user's authorized limits. Common manifestations include violation of the principle of least privilege, bypassing access control checks through URL parameter tampering or API request modification, insecure direct object references, missing access controls on API endpoints, elevation of privilege, metadata manipulation of tokens and cookies, and CORS misconfiguration. Access control weaknesses are pervasive across web applications, with 100% of tested applications exhibiting some form of this vulnerability.

Risk

• Unauthorized access to sensitive data belonging to other users or the organization.
• Modification or destruction of records the attacker should not be able to reach.
• Elevation of privilege from a standard user to an administrator role.
• Business logic bypass enabling actions outside the intended user workflow.
• Lateral movement across accounts through insecure direct object references.
• Server-side request forgery when access controls do not restrict internal resource access.
• Cross-site request forgery when anti-CSRF protections are absent or misconfigured.

Vulnerability checklist

• Access is not denied by default; resources are available to anyone unless explicitly restricted.
• Access control checks can be bypassed by modifying the URL, application state, or API requests.
• Users can view or edit other users' records by supplying a different unique identifier.
• API endpoints for POST, PUT, and DELETE operations lack access control enforcement.
• A user can act as another user or gain administrator privileges without proper authentication.
• JWT tokens, cookies, or hidden fields can be tampered with to elevate privileges.
• CORS policy allows API access from unauthorized or untrusted origins.
• Authenticated pages are accessible to unauthenticated users through forced browsing.
• File metadata, backup files, or source control directories are present within web roots.

Prevention controls

1. Deny access by default for all resources except those explicitly designated as public. 2. Implement access control mechanisms once and reuse them consistently throughout the application, including minimizing CORS usage. 3. Enforce record ownership in access control models rather than allowing users to create, read, update, or delete any record. 4. Enforce unique business limit requirements through domain models. 5. Disable web server directory listing and remove file metadata and backup files from web roots. 6. Log all access control failures and alert administrators on repeated failures. 7. Implement rate limits on API and controller access to reduce harm from automated attacks. 8. Invalidate stateful session identifiers on the server after logout and use short-lived stateless JWT tokens with refresh token rotation following OAuth standards. 9. Use well-established toolkits or patterns that provide simple, declarative access controls. 10. Include functional access control tests in unit and integration test suites.

Example attack scenarios

Scenario A — Insecure direct object reference

An application uses unverified data in a SQL call to access account information:

pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

An attacker modifies the browser's acct parameter to send any desired account number. The application returns the other user's data because it does not verify ownership:

https://example.com/app/accountInfo?acct=notmyacct

Scenario B — Forced browsing to admin pages

An attacker forces the browser to target URLs that require admin rights:

https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo

If an unauthenticated user can access either page, it is a flaw. If a non-admin can access the admin page, it is a flaw.

Scenario C — Client-side only access control

An application enforces all access control in its frontend JavaScript. While the attacker cannot reach the admin endpoint through the browser, they bypass it entirely:

curl https://example.com/app/admin_getappInfo

The server returns the admin page because it does not enforce server-side access controls.

Detection guidance

• Review application code for consistent enforcement of access control checks on all endpoints.
• Test for insecure direct object references by substituting resource identifiers in requests.
• Verify that forced browsing to authenticated or privileged pages fails for unauthorized users.
• Inspect CORS configuration for overly permissive origin policies.
• Check for the presence of file metadata, backup files, and source control directories in

web-accessible paths.

• Monitor access control failure logs for patterns indicating automated or targeted attacks.

Remediation

• Implement server-side access control enforcement on all endpoints and resource operations.
• Remove all file metadata, backup files, and source control directories from web roots.
• Restrict CORS policies to trusted origins only.
• Add access control failure logging with alerting for repeated violations.
• Invalidate sessions on logout and enforce session timeout policies.
• Conduct access control penetration testing and remediate all identified bypasses.

---

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Modifications: Restructured into agent-consumable reference format with added detection and remediation guidance.

02 Security Misconfiguration

Identifier: A02:2025 Category: Configuration Management

Description

Security misconfiguration occurs when a system, application, or cloud service is set up incorrectly from a security perspective, creating exploitable vulnerabilities. This includes missing security hardening across the application stack, unnecessary features or services left enabled, unchanged default credentials, overly informative error messages exposed to users, disabled or improperly configured security features in upgraded systems, insecure settings in application servers, frameworks, libraries, and databases, and missing or weak security headers. With increasing adoption of highly configurable software and cloud services, misconfiguration has become one of the most prevalent web application security risks.

Risk

• Full application or server compromise through unprotected administrative interfaces with

default credentials.

• Information disclosure through detailed error messages, stack traces, or directory listings

exposed to users.

• Unauthorized access through unnecessary ports, services, accounts, or privileges left enabled.
• Data exposure through misconfigured cloud storage permissions.
• Weakened defense-in-depth when security features are disabled for backward compatibility.
• Exploitation of known vulnerabilities in components running insecure default configurations.

Vulnerability checklist

• Security hardening is missing or improperly configured across any part of the application stack.
• Unnecessary features, ports, services, pages, accounts, or privileges are enabled or installed.
• Default accounts and their passwords are still enabled and unchanged.
• Error handling reveals stack traces or overly informative error messages to users.
• Security features in upgraded systems are disabled or not configured securely.
• Security settings in application servers, frameworks, libraries, and databases are not set to

secure values.

• The server does not send security headers or directives, or they are not set to secure values.
• Cloud storage permissions are overly permissive.
• Static keys or secrets are embedded in code, configuration files, or pipelines.

Prevention controls

1. Implement a repeatable hardening process that enables fast and consistent deployment of locked-down environments across development, QA, and production. 2. Deploy a minimal platform without unnecessary features, components, documentation, or samples. 3. Review and update configurations as part of the patch management process, including cloud storage permissions. 4. Implement a segmented application architecture with effective separation between components or tenants using containerization or cloud security groups. 5. Send security directives to clients through security headers. 6. Automate verification of configuration effectiveness across all environments. 7. Implement central configuration to intercept excessive error messages. 8. Use identity federation, short-lived credentials, or role-based access mechanisms instead of embedding static keys or secrets.

Example attack scenarios

Scenario A — Unremoved sample applications

An application server ships with sample applications that are not removed from the production server. The sample applications have known security flaws that an attacker exploits to compromise the server. The admin console retains default credentials, and the attacker logs in and takes over.

Scenario B — Directory listing exposure

Directory listing is not disabled on the server. An attacker discovers the listing, downloads compiled Java class files, decompiles them, and finds a severe access control flaw in the application source code.

Scenario C — Detailed error messages

The application server returns detailed error messages including stack traces to users. The error output exposes component versions known to be vulnerable and internal system information that the attacker uses to craft targeted exploits.

Scenario D — Permissive cloud storage

A cloud service provider defaults to sharing permissions open to the internet. Sensitive data stored in cloud storage is accessible to anyone without authentication.

Detection guidance

• Run automated configuration scanners against all environments to detect deviations from

hardened baselines.

• Check for the presence of default accounts and credentials on all application components.
• Verify that error messages returned to users do not contain stack traces or internal system

details.

• Inspect HTTP response headers for missing or misconfigured security directives.
• Review cloud storage permissions for public or overly permissive access policies.
• Audit application servers, frameworks, and libraries for insecure default settings.

Remediation

• Remove all unnecessary features, components, sample applications, documentation, and default

accounts from production environments.

• Apply hardened configuration baselines to all application servers, frameworks, and libraries.
• Configure error handling to return generic messages to users and log detailed errors internally.
• Enable and properly configure all security headers and directives.
• Restrict cloud storage permissions to authorized principals only.
• Automate configuration verification and schedule recurring audits to detect drift.

---

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Modifications: Restructured into agent-consumable reference format with added detection and remediation guidance.

03 Software Supply Chain Failures

Identifier: A03:2025 Category: Supply Chain

Description

Software supply chain failures are breakdowns or compromises in the process of building, distributing, or updating software. They are caused by vulnerabilities or malicious changes in third-party code, tools, or other dependencies that the system relies on. The risk scope includes direct dependencies, transitive dependencies, build tools, CI/CD pipelines, IDE extensions, artifact repositories, container registries, and any other component in the software delivery chain. This vulnerability ranked number one in the OWASP Top 10 community survey, reflecting the growing severity and frequency of supply chain attacks.

Risk

• Full system compromise through a compromised trusted vendor distributing malicious updates.
• Remote code execution through vulnerable third-party libraries or frameworks included in the

application.

• Data exfiltration through malicious packages that harvest credentials, tokens, or sensitive

data from developer environments.

• Self-propagating attacks through supply chain worms that use compromised tokens to push

malicious versions of accessible packages.

• Widespread organizational exposure when CI/CD pipelines have weaker security than the systems

they build and deploy.

• Loss of patching capability when components reach end of life without a migration plan.

Vulnerability checklist

• The versions of all components (direct and transitive dependencies) are not tracked.
• Software components are vulnerable, unsupported, or out of date, including the OS, web server,

DBMS, APIs, runtime environments, and libraries.

• Regular vulnerability scanning and security bulletin subscriptions are not in place for

deployed components.

• No change management process tracks modifications to CI/CD settings, code repositories,

developer IDEs, artifact repositories, or third-party integrations.

• Supply chain systems lack hardened access controls and least privilege enforcement.
• No separation of duty exists; a single person can write code and promote it to production

without oversight.

• Components from untrusted sources are used in or can impact production environments.
• Patching is deferred on a monthly or quarterly schedule, leaving extended exposure windows.
• Library compatibility is not tested after updates or upgrades.
• The CI/CD pipeline is complex and has weaker security than the systems it deploys.

Prevention controls

1. Generate and centrally manage a Software Bill of Materials (SBOM) for the entire software stack, including transitive dependencies. 2. Continuously inventory and monitor component versions using tools such as OWASP Dependency Track, OWASP Dependency Check, or retire.js. 3. Monitor CVE, NVD, and OSV databases for vulnerabilities in deployed components, and subscribe to vendor security advisories. 4. Obtain components only from official trusted sources over secure links and prefer signed packages. 5. Deliberately choose dependency versions and upgrade only when there is a documented need. 6. Remove unused dependencies, unnecessary features, components, files, and documentation to reduce attack surface. 7. Monitor for unmaintained libraries and plan migration to alternatives when patching is not possible. 8. Update CI/CD, IDE, and all developer tooling regularly. 9. Use staged rollouts or canary deployments to limit exposure from compromised vendor updates. 10. Harden code repositories, developer workstations, build servers, artifact repositories, and infrastructure-as-code with MFA, access control, signed builds, and tamper-evident logs. 11. Implement separation of duties so that no single person can promote code to production without review.

Example attack scenarios

Scenario A — Compromised trusted vendor

A trusted software vendor is compromised with malware. Organizations that upgrade to the compromised version have their systems backdoored. The 2019 SolarWinds attack compromised approximately 18,000 organizations through this vector.

Scenario B — Self-propagating package worm

An attacker seeds malicious versions of popular npm packages that execute post-install scripts to harvest and exfiltrate sensitive data. The malware detects npm tokens in victim environments and uses them to push malicious versions of any accessible package. The worm reaches over 500 package versions before disruption.

Scenario C — Vulnerable third-party library

An application includes a third-party library with a known remote code execution vulnerability. The vulnerability has been publicly disclosed for months but the application has not been updated. Attackers fingerprint the service version and exploit the flaw to gain a foothold.

Detection guidance

• Continuously scan all dependencies for known vulnerabilities using software composition

analysis tools.

• Monitor SBOM outputs for newly disclosed vulnerabilities affecting deployed components.
• Track component build dates and compare against current upstream releases.
• Audit CI/CD pipeline configurations and access logs for unauthorized changes.
• Verify that all deployed artifacts are signed and that signatures are validated before

deployment.

• Review developer workstations and build environments for unauthorized IDE extensions or tools.

Remediation

• Update all vulnerable dependencies to patched versions immediately.
• Rebuild and redeploy applications from updated base images and libraries.
• Decommission or isolate components that have reached end of life.
• Harden CI/CD pipelines with access controls, signed builds, and separation of duties.
• Establish automated patch scanning and notification for all dependency domains.
• Validate that deployed artifacts match expected signed versions.

---

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Modifications: Restructured into agent-consumable reference format with added detection and remediation guidance.

04 Cryptographic Failures

Identifier: A04:2025 Category: Cryptography

Description

Cryptographic failures encompass the lack of cryptography, use of insufficiently strong cryptographic algorithms, leaking of cryptographic keys, and related implementation errors. All data in transit should be encrypted at the transport layer, and sensitive data at rest requires encryption appropriate to its classification. Sensitive data such as passwords, credit card numbers, health records, personal information, and business secrets require additional protection, especially when subject to privacy laws such as GDPR or regulations such as PCI DSS. Common weaknesses include use of old or weak algorithms, default or reused crypto keys, missing enforcement of encryption via security headers, improper certificate validation, use of insecure modes of operation, and reliance on deprecated hash functions.

Risk

• Exposure of sensitive data in transit through downgrade attacks or missing TLS enforcement.
• Mass credential compromise when password databases use unsalted or weak hashing algorithms.
• Cryptographic key leakage through source code repositories or insecure key management.
• Data exposure through cleartext storage of sensitive information at rest.
• Algorithm downgrade or bypass attacks that weaken or eliminate cryptographic protections.
• Side-channel attacks exploiting cryptographic error messages such as padding oracle attacks.
• Future exposure of currently encrypted data when post-quantum cryptography migration is delayed.

Vulnerability checklist

• Old or weak cryptographic algorithms or protocols are used by default or in legacy code.
• Default crypto keys are in use, weak keys are generated, or proper key rotation is missing.
• Crypto keys are checked into source code repositories.
• Encryption is not enforced through HTTP security headers or directives.
• Server certificate and trust chain validation is missing or incomplete.
• Initialization vectors are ignored, reused, or insufficiently random for the cryptographic mode.
• Insecure modes of operation such as ECB are used, or encryption is used where authenticated

encryption is required.

• Passwords are used as cryptographic keys without a password-based key derivation function.
• Randomness sources are not cryptographically secure or are seeded with insufficient entropy.
• Deprecated hash functions such as MD5 or SHA1 are used for cryptographic purposes.

Prevention controls

1. Classify data processed, stored, and transmitted by the application and identify which data is sensitive according to privacy laws, regulatory requirements, or business needs. 2. Store the most sensitive keys in hardware or cloud-based HSMs. 3. Use well-trusted implementations of cryptographic algorithms. 4. Discard sensitive data as soon as possible or use PCI DSS compliant tokenization or truncation. 5. Encrypt all sensitive data at rest using strong algorithms and proper key management. 6. Encrypt all data in transit with TLS 1.2 or higher with forward secrecy ciphers and enforce encryption using HSTS. 7. Disable caching for responses that contain sensitive data. 8. Store passwords using strong adaptive and salted hashing functions such as Argon2, scrypt, or PBKDF2-HMAC-SHA-512 with appropriate work factors. 9. Generate initialization vectors appropriate for the mode of operation using a CSPRNG and never reuse an IV for a fixed key. 10. Use authenticated encryption instead of encryption alone. 11. Generate keys cryptographically randomly and avoid using deprecated cryptographic functions, block modes, and padding schemes. 12. Prepare for post-quantum cryptography migration so that high-risk systems are protected by the end of 2030.

Example attack scenarios

Scenario A — Missing TLS enforcement

A site does not enforce TLS for all pages or supports weak encryption. An attacker monitoring network traffic at an insecure wireless network downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user's session cookie. The attacker replays the cookie and hijacks the authenticated session.

Scenario B — Weak password hashing

A password database uses unsalted or simple hashes to store passwords. An attacker retrieves the password database through a file upload vulnerability. All unsalted hashes are exposed with a rainbow table of pre-calculated hashes, and weakly salted hashes are cracked by GPU.

Detection guidance

• Scan all endpoints for TLS configuration strength and protocol version support.
• Verify that HSTS headers are present and correctly configured on all responses.
• Audit password storage implementations for use of appropriate adaptive hashing algorithms.
• Search source code repositories for committed cryptographic keys or secrets.
• Review cryptographic algorithm and mode selections in application code for deprecated or

weak choices.

• Test for padding oracle and other side-channel vulnerabilities in cryptographic operations.

Remediation

• Upgrade all TLS configurations to version 1.2 or higher with forward secrecy ciphers.
• Enable HSTS on all domains and subdomains.
• Rotate all cryptographic keys that may have been exposed and remove keys from source

repositories.

• Re-hash all passwords using strong adaptive algorithms with appropriate work factors.
• Replace all deprecated cryptographic algorithms and insecure modes of operation.
• Deploy automated scanning for cryptographic configuration weaknesses across all environments.

---

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Modifications: Restructured into agent-consumable reference format with added detection and remediation guidance.

05 Injection

Identifier: A05:2025 Category: Input Validation

Description

Injection vulnerabilities occur when an application sends untrusted user input to an interpreter and the interpreter executes parts of that input as commands. This happens when user-supplied data is not validated, filtered, or sanitized, when dynamic queries or non-parameterized calls are used without context-aware escaping, when hostile data is used within ORM search parameters, or when hostile data is directly concatenated into dynamic queries, commands, or stored procedures. Common injection types include SQL, NoSQL, OS command, ORM, LDAP, Expression Language, and cross-site scripting. Injection is one of the most tested vulnerability categories, with 100% of applications tested for some form of injection, and it has the greatest number of CVEs of any category.

Risk

• Full database compromise through SQL injection enabling unauthorized data access, modification,

or deletion.

• Remote code execution on the server through OS command injection.
• Cross-site scripting enabling session hijacking, credential theft, and defacement.
• LDAP injection enabling authentication bypass and directory information disclosure.
• ORM injection enabling unauthorized data extraction through manipulated query parameters.
• Server-side template injection enabling arbitrary code execution within the application context.
• Stored injection attacks that execute against all users who access the compromised data.

Vulnerability checklist

• User-supplied data is not validated, filtered, or sanitized before processing.
• Dynamic queries or non-parameterized calls are used without context-aware escaping.
• Hostile data is used within ORM search parameters to extract additional records.
• Hostile data is directly concatenated into SQL queries, OS commands, or LDAP queries.
• User-supplied structure names such as table names or column names are used in dynamic queries.
• The application does not use parameterized interfaces or safe APIs that avoid interpreter use.
• Source code review and automated testing (SAST, DAST, IAST) are not integrated into the

CI/CD pipeline.

Prevention controls

1. Use safe APIs that provide parameterized interfaces or migrate to Object Relational Mapping tools to avoid using the interpreter directly. 2. Use positive server-side input validation for all user-supplied data. 3. Escape special characters using the specific escape syntax for the target interpreter for any residual dynamic queries. 4. Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection. 5. Integrate SAST, DAST, and IAST tools into the CI/CD pipeline to detect injection flaws before production deployment. 6. Avoid concatenating user input into queries even when using ORM frameworks. 7. Never use user-supplied values as SQL structure names such as table or column identifiers.

Example attack scenarios

Scenario A — SQL injection via parameter manipulation

An application uses untrusted data in the construction of a vulnerable SQL call:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

An attacker modifies the id parameter value in the browser to send ' OR '1'='1:

http://example.com/app/accountView?id=' OR '1'='1

This changes the meaning of the query to return all records from the accounts table.

Scenario B — ORM injection

An application uses Hibernate Query Language but constructs queries by concatenating user input:

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

An attacker supplies ' OR custID IS NOT NULL OR custID=' which bypasses the filter and returns all accounts. While HQL has fewer dangerous functions than raw SQL, unauthorized data access still occurs.

Scenario C — OS command injection

An application passes user input directly to an OS command without sanitization:

String cmd = "nslookup " + request.getParameter("domain");
Runtime.getRuntime().exec(cmd);

An attacker supplies example.com; cat /etc/passwd to execute arbitrary commands on the server.

Detection guidance

• Review source code for dynamic query construction that concatenates user input.
• Run automated SAST scans to identify injection-prone code patterns.
• Execute DAST scans against all application endpoints with injection payloads.
• Fuzz all parameters, headers, URLs, cookies, and data inputs for injection responses.
• Inspect parameterized query usage to verify that parameters are not bypassed through

concatenation.

• Monitor application logs for SQL errors, command execution failures, or unexpected query

patterns.

Remediation

• Replace all dynamic query construction with parameterized queries or safe APIs.
• Add server-side input validation to all user-supplied data entry points.
• Apply context-appropriate output encoding and escaping to all dynamic content.
• Remove or replace any code that concatenates user input into interpreter commands.
• Deploy WAF rules to block common injection patterns as an interim measure while code is

remediated.

• Re-test all remediated endpoints with injection payloads to confirm the fix.

---

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Modifications: Restructured into agent-consumable reference format with added detection and remediation guidance.

06 Insecure Design

Identifier: A06:2025 Category: Architecture and Design

Description

Insecure design is a broad category representing missing or ineffective security control design at the architectural level. This is distinct from implementation defects; a secure design can still have implementation vulnerabilities, but an insecure design cannot be fixed by a perfect implementation because the necessary security controls were never created. The root cause is a lack of business risk profiling during the design phase and the failure to determine what level of security design is required. The category calls for increased use of threat modeling, secure design patterns, and reference architectures. Key aspects include requirements and resource management, secure design methodology, and a secure development lifecycle with threat modeling integrated into refinement sessions.

Risk

• Business logic bypass enabling actions outside the intended user workflow, such as bulk

reservation abuse or scalper bot exploitation.

• Missing security controls that cannot be retroactively added through code fixes alone.
• Credential recovery mechanisms that rely on insecure methods such as knowledge-based questions.
• Insufficient tenant segregation enabling cross-tenant data access or interference.
• Missing rate limiting allowing automated abuse of business-critical functionality.
• Inadequate threat modeling resulting in unidentified attack vectors persisting through

production.

Vulnerability checklist

• No threat modeling is performed during the design phase of the application.
• Business requirements do not include protection requirements for confidentiality, integrity,

availability, and authenticity of data assets.

• No secure design patterns or reference architectures are used.
• Security controls are not integrated into user stories.
• Plausibility checks are missing from application tiers.
• Unit and integration tests do not validate resistance to the threat model.
• Tenant segregation is absent or insufficient at system and network layers.
• The application uses insecure credential recovery mechanisms such as knowledge-based questions.
• No secure development lifecycle is established or followed.

Prevention controls

1. Establish and use a secure development lifecycle with application security professionals to evaluate and design security and privacy controls. 2. Establish and use a library of secure design patterns or paved-road components. 3. Use threat modeling for critical application areas including authentication, access control, business logic, and key flows. 4. Integrate security language and controls into user stories. 5. Integrate plausibility checks at each tier of the application from frontend to backend. 6. Write unit and integration tests that validate all critical flows against the threat model, including both use cases and misuse cases. 7. Segregate tier layers on system and network layers depending on exposure and protection needs. 8. Segregate tenants robustly by design throughout all tiers.

Example attack scenarios

Scenario A — Insecure credential recovery

A credential recovery workflow includes knowledge-based questions and answers. The questions and answers cannot be trusted as evidence of identity because multiple people may know the answers. An attacker answers the questions using publicly available information and resets the victim's password.

Scenario B — Business logic abuse

A cinema chain allows group booking discounts with a maximum of fifteen attendees before requiring a deposit. An attacker exploits the flow to book six hundred seats across all cinemas in a few requests, causing massive revenue loss without making a deposit.

Scenario C — Scalper bot exploitation

A retail e-commerce site does not implement anti-bot protections or rate limiting. Scalper bots purchase all available high-demand inventory within seconds of release. Legitimate customers cannot purchase the products at listed prices.

Detection guidance

• Review the application design documentation for the presence of threat models and secure

design artifacts.

• Verify that security requirements are documented in user stories and business requirements.
• Test business logic flows for abuse scenarios including bulk operations, rate limits, and

state manipulation.

• Inspect tenant segregation at all tiers to confirm that cross-tenant access is not possible.
• Check credential recovery mechanisms for reliance on knowledge-based questions or other

insecure methods.

• Review unit and integration tests for coverage of misuse cases and threat model scenarios.

Remediation

• Conduct threat modeling for all critical application areas and implement identified controls.
• Replace insecure credential recovery mechanisms with secure alternatives such as

multi-factor authentication or secure token-based recovery.

• Implement rate limiting and anti-bot protections on all business-critical endpoints.
• Add plausibility checks and business logic validation at each application tier.
• Ensure tenant segregation is enforced at system and network layers.
• Integrate security testing including misuse case validation into the CI/CD pipeline.

---

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Modifications: Restructured into agent-consumable reference format with added detection and remediation guidance.

07 Authentication Failures

Identifier: A07:2025 Category: Authentication

Description

Authentication failures occur when an application allows attackers to trick it into recognizing an invalid or incorrect user as legitimate. Common weaknesses include permitting automated credential stuffing and brute force attacks, allowing default or well-known passwords, using weak or ineffective credential recovery mechanisms, storing passwords in plain text or with weak hashing, missing or ineffective multi-factor authentication, exposing session identifiers in URLs, reusing session identifiers after login, and failing to invalidate sessions on logout or after inactivity. Hybrid password attacks that increment or adjust breached credentials represent an evolving form of credential stuffing.

Risk

• Complete account takeover through credential stuffing or brute force attacks.
• Mass compromise of user accounts when breached credential lists are not checked during

registration or password changes.

• Session hijacking through exposed or non-invalidated session identifiers.
• Persistent unauthorized access when SSO sessions are not properly terminated across all

federated applications.

• Authentication bypass through weak or ineffective fallback mechanisms when MFA is unavailable.
• Unauthorized access to administrative accounts through unchanged default credentials.

Vulnerability checklist

• Automated attacks such as credential stuffing and brute force are not blocked or rate limited.
• Default, weak, or well-known passwords are permitted.
• New accounts can be created with known-breached credentials.
• Weak or ineffective credential recovery processes such as knowledge-based answers are used.
• Passwords are stored in plain text, encrypted reversibly, or with weak hash algorithms.
• Multi-factor authentication is missing or has weak fallback options.
• Session identifiers are exposed in URLs or insecure locations.
• Session identifiers are reused after successful login.
• Sessions and authentication tokens are not invalidated on logout or after inactivity.
• JWT scope and audience claims are not validated.

Prevention controls

1. Implement and enforce multi-factor authentication on all critical systems to prevent credential stuffing, brute force, and stolen credential reuse. 2. Do not ship or deploy with default credentials, especially for administrator accounts. 3. Implement weak password checks against the top 10,000 worst passwords list. 4. Validate new and changed passwords against lists of known breached credentials. 5. Align password policies with NIST 800-63b section 5.1.1 guidelines for memorized secrets. 6. Do not force password rotation unless a breach is suspected; force immediate resets on suspected breach. 7. Harden registration, credential recovery, and API pathways against account enumeration by using identical response messages for all outcomes. 8. Limit and increasingly delay failed login attempts and alert administrators on detected attacks. 9. Use a server-side session manager that generates high-entropy random session IDs after login, stores them in secure cookies, and invalidates them on logout and after timeouts. 10. Validate JWT audience, issuer, and scope claims on all token-based authentication. 11. Use a well-trusted, hardened identity and session management system.

Example attack scenarios

Scenario A — Hybrid credential stuffing

An attacker uses breached username and password lists and applies common password adjustments such as incrementing numbers or changing seasons. The application does not implement defenses against automated threats. The attacker gains unauthorized access to accounts whose users follow predictable password patterns.

Scenario B — Missing multi-factor authentication

An organization relies on passwords as the sole authentication factor. Password rotation and complexity requirements encourage users to reuse weak passwords. An attacker compromises accounts using credential dumps without encountering a second authentication factor.

Scenario C — Incomplete session termination

A user logs out of an SSO-protected application, but the single logout does not terminate sessions in all federated applications. An attacker who gains access to the browser accesses the still-authenticated applications and takes over the victim's accounts.

Detection guidance

• Test login endpoints for resistance to automated credential stuffing and brute force attacks.
• Verify that default credentials are not present on any deployed component.
• Inspect password storage implementations for use of strong adaptive hashing algorithms.
• Confirm that MFA is enforced on all administrative and high-privilege accounts.
• Check that session identifiers are regenerated after login and invalidated on logout.
• Monitor authentication logs for patterns indicating credential stuffing or brute force attacks.

Remediation

• Enable MFA on all user-facing and administrative authentication flows.
• Remove all default credentials from deployed systems.
• Migrate password storage to strong adaptive hashing algorithms with appropriate work factors.
• Implement account lockout or progressive delay policies on failed login attempts.
• Regenerate session identifiers on login and ensure complete session invalidation on logout.
• Deploy monitoring and alerting for authentication anomalies and attack patterns.

---

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Modifications: Restructured into agent-consumable reference format with added detection and remediation guidance.

08 Software or Data Integrity Failures

Identifier: A08:2025 Category: Data Integrity

Description

Software or data integrity failures occur when code and infrastructure do not protect against invalid or untrusted code or data being treated as trusted and valid. This includes applications that rely on plugins, libraries, or modules from untrusted sources, repositories, or content delivery networks without verifying integrity. Insecure CI/CD pipelines that do not consume and provide software integrity checks introduce potential for unauthorized access, malicious code, or system compromise. Auto-update functionality that downloads and applies updates without sufficient integrity verification is another common vector. Insecure deserialization, where objects or data encoded into a structure that an attacker can see and modify, allows tampering with application state or achieving remote code execution.

Risk

• Remote code execution through insecure deserialization of untrusted data.
• System compromise through unsigned or unverified software updates applied automatically.
• Session hijacking through inclusion of functionality from untrusted control spheres such as

third-party domains sharing the application cookie scope.

• Supply chain compromise through code or artifacts pulled from untrusted sources without

integrity verification.

• Data tampering when serialized data is exchanged with untrusted clients without integrity

checks.

• Malicious code introduction through packages downloaded from unofficial sources without

signature verification.

Vulnerability checklist

• The application relies on plugins, libraries, or modules from untrusted sources without

verifying integrity.

• The CI/CD pipeline does not verify the integrity of code or artifacts before use.
• Auto-update functionality downloads and applies updates without sufficient integrity

verification.

• Unsigned or unencrypted serialized data is received from untrusted clients without integrity

checks.

• Code or configuration changes are not subject to a review process to prevent malicious

introduction.

• The application includes functionality loaded from untrusted third-party domains.
• Digital signatures or checksums are not used to verify software or data authenticity.
• The CI/CD pipeline lacks proper segregation, access control, and configuration hardening.

Prevention controls

1. Use digital signatures or similar mechanisms to verify that software or data is from the expected source and has not been altered. 2. Consume libraries and dependencies only from trusted repositories and consider hosting an internal vetted repository for higher-risk profiles. 3. Ensure a review process exists for code and configuration changes to minimize introduction of malicious code. 4. Ensure the CI/CD pipeline has proper segregation, configuration, and access control to maintain code integrity through build and deploy processes. 5. Do not receive unsigned or unencrypted serialized data from untrusted clients without integrity checks or digital signatures to detect tampering or replay. 6. Verify the integrity of all externally sourced packages and updates through signature validation before use.

Example attack scenarios

Scenario A — Third-party domain cookie theft

A company maps a third-party support provider to a subdomain of its main domain. Authentication cookies set on the main domain are sent to the third-party provider. Anyone with access to the provider's infrastructure can steal user cookies and perform session hijacking.

Scenario B — Unsigned firmware updates

A device downloads firmware updates without verifying digital signatures. An attacker intercepts the update process and distributes a modified firmware image containing a backdoor. There is no mechanism to remediate other than waiting for a signed update to replace the compromised version.

Scenario C — Insecure deserialization

An application serializes user state and passes it with each request. An attacker recognizes the serialized Java object signature, uses a deserialization scanner to identify a vulnerable gadget chain, and gains remote code execution on the application server.

Detection guidance

• Verify that digital signatures are required and validated for all externally sourced packages,

libraries, and updates.

• Inspect CI/CD pipeline configurations for integrity verification steps on all consumed

artifacts.

• Audit auto-update mechanisms for signature validation before application of updates.
• Review application code for deserialization of data from untrusted sources.
• Check that code and configuration changes require review before merge and deployment.
• Monitor for inclusion of resources from untrusted third-party domains.

Remediation

• Implement digital signature verification for all externally sourced software and data.
• Add integrity checks to all CI/CD pipeline stages for consumed and produced artifacts.
• Replace insecure deserialization with safer data exchange formats or add integrity validation

to serialized data.

• Restrict auto-update functionality to accept only signed updates from trusted sources.
• Enforce mandatory code review for all changes before deployment.
• Remove or replace functionality loaded from untrusted third-party domains.

---

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Modifications: Restructured into agent-consumable reference format with added detection and remediation guidance.

09 Security Logging and Alerting Failures

Identifier: A09:2025 Category: Logging and Monitoring

Description

Security logging and alerting failures occur when applications cannot detect, escalate, or alert on active attacks in real time or near real time. Without sufficient logging, monitoring, and alerting, breaches cannot be detected and incidents cannot be responded to effectively. Common weaknesses include auditable events not being logged or logged inconsistently, warnings and errors generating inadequate log messages, log integrity not being protected from tampering, logs not being monitored for suspicious activity, logs stored only locally without backups, missing alerting thresholds and escalation processes, penetration testing and DAST scans not triggering alerts, sensitive information leaking into logs, and log data not being encoded to prevent injection attacks against logging systems.

Risk

• Breaches persisting undetected for extended periods due to lack of monitoring and alerting.
• Inability to perform forensic analysis when logging is insufficient or logs are not retained.
• Regulatory penalties when logging and monitoring requirements mandated by compliance frameworks

are not met.

• Sensitive data exposure through logs that are visible to unauthorized users or that contain PII.
• Log injection attacks that corrupt log data or exploit monitoring systems when log output is

not encoded.

• Alert fatigue from excessive false positives preventing identification of genuine attacks.
• Inability to respond to incidents when playbooks for alerting use cases are missing or outdated.

Vulnerability checklist

• Auditable events such as logins, failed logins, and high-value transactions are not logged or

logged inconsistently.

• Warnings and errors generate no, inadequate, or unclear log messages.
• Log integrity is not protected from tampering.
• Application and API logs are not monitored for suspicious activity.
• Logs are only stored locally and not backed up.
• Alerting thresholds and response escalation processes are not in place or are ineffective.
• Penetration testing and DAST scans do not trigger alerts.
• The application cannot detect or alert on active attacks in real time.
• Logging and alerting events are visible to unauthorized users or attackers.
• Log data is not encoded correctly, enabling injection attacks against logging systems.
• Detected alerts cannot be processed because playbooks are incomplete or outdated.

Prevention controls

1. Log all login, access control, and server-side input validation failures with sufficient user context for forensic analysis. 2. Log every security control invocation, whether it succeeds or fails. 3. Generate logs in a format that log management solutions can easily consume. 4. Encode log data correctly to prevent injection attacks against logging and monitoring systems. 5. Ensure all transactions have an audit trail with integrity controls such as append-only database tables to prevent tampering or deletion. 6. Ensure all transactions that throw an error are rolled back and fail closed. 7. Establish effective monitoring and alerting use cases with playbooks so suspicious activities are detected and responded to by the security operations team. 8. Deploy honeytokens in the application and database to detect unauthorized access with minimal false positives. 9. Establish or adopt an incident response and recovery plan. 10. Limit or rate-limit repeated identical errors to prevent log flooding and append statistical summaries to the original message.

Example attack scenarios

Scenario A — Undetected long-term breach

A health plan provider lacks monitoring and logging on its website. An attacker accesses and modifies thousands of sensitive health records over a period of years. The breach is discovered only when an external party reports it.

Scenario B — Third-party cloud breach

An airline's data is hosted by a third-party cloud provider. The provider detects a breach involving years of passenger personal data, passport details, and credit card information. The airline is notified after the breach has already occurred and has limited forensic capability.

Scenario C — Undetected payment skimming

An airline's payment application has security vulnerabilities exploited by attackers who harvest over 400,000 customer payment records. The breach leads to a regulatory fine of 20 million pounds because logging and monitoring did not detect the attack.

Detection guidance

• Verify that all auditable events generate log entries with sufficient context.
• Confirm that log integrity is protected through append-only storage or similar controls.
• Test whether DAST scans and penetration testing activities trigger alerts.
• Review alerting rules for appropriate thresholds and confirm that alerts are received and

reviewed within a defined time window.

• Check that logs are forwarded to centralized log management and backed up.
• Inspect log output for sensitive information that should not be logged.

Remediation

• Implement comprehensive logging for all authentication, access control, and security events.
• Deploy centralized log management with tamper-evident storage and offsite backup.
• Configure alerting rules with appropriate thresholds and escalation procedures.
• Create and maintain incident response playbooks for all alerting use cases.
• Encode all log output to prevent log injection vulnerabilities.
• Conduct a logging and monitoring gap analysis and remediate identified deficiencies.

---

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Modifications: Restructured into agent-consumable reference format with added detection and remediation guidance.

10 Mishandling of Exceptional Conditions

Identifier: A10:2025 Category: Error Handling

Description

Mishandling of exceptional conditions occurs when applications fail to prevent, detect, and respond to unusual and unpredictable situations, leading to crashes, unexpected behavior, and security vulnerabilities. This involves three failure modes: the application does not prevent an unusual situation from occurring, it does not identify the situation as it happens, or it responds poorly or not at all afterward. Exceptional conditions can be caused by missing or incomplete input validation, late or high-level error handling instead of handling at the function where errors occur, unexpected environmental states such as memory or network issues, inconsistent exception handling, or exceptions that are not handled at all, leaving the system in an unknown state. The resulting vulnerabilities include logic bugs, overflows, race conditions, fraudulent transactions, and issues with memory, state, resource, timing, authentication, and authorization.

Risk

• Denial of service through resource exhaustion when exceptions do not properly release allocated

resources.

• Sensitive data exposure through error messages that reveal system internals, stack traces, or

database structure.

• State corruption in financial transactions when multi-step operations are not rolled back on

failure.

• Race conditions exploitable by attackers interrupting transactions at critical points.
• Authentication and authorization bypass when error handling falls through to permissive default

states.

• System instability from uncaught exceptions leaving the application in an unknown and

unpredictable state.

Vulnerability checklist

• Exceptions are caught at a high level but not handled at the functions where they occur.
• Error messages expose sensitive system information including stack traces, database structure,

or component versions.

• Resources are not released when exceptions are thrown, leading to memory leaks or resource

exhaustion.

• Multi-step transactions are not rolled back completely when an error occurs mid-transaction.
• Exceptional conditions are not logged or alerted on, preventing detection of ongoing attacks.
• No global exception handler exists as a safety net for unhandled exceptions.
• Error handling is implemented inconsistently across different parts of the application.
• Rate limiting, resource quotas, and throttling are not implemented to prevent exceptional

conditions from occurring.

• Identical repeated errors are not aggregated, leading to log flooding.

Prevention controls

1. Catch every possible error directly at the function where it occurs and handle it with a meaningful recovery action. 2. Implement a global exception handler as a safety net for any unhandled exceptions. 3. Ensure all transactions that throw an error are rolled back completely and fail closed. 4. Include error logging and alerting as part of every exception handling path. 5. Return generic error messages to users and log detailed error information internally. 6. Add rate limiting, resource quotas, and throttling to prevent exceptional conditions from occurring. 7. Aggregate identical repeated errors above a threshold into statistical summaries appended to the original message. 8. Implement centralized error handling so that the entire application handles exceptions consistently. 9. Perform strict input validation with sanitization to prevent exceptional conditions from reaching internal functions. 10. Execute stress, performance, and penetration testing to identify error handling weaknesses.

Example attack scenarios

Scenario A — Resource exhaustion through exception handling

An application catches exceptions during file uploads but does not release resources after each exception. Each new exception leaves resources locked or unavailable. An attacker repeatedly triggers the exception until all resources are consumed and the application becomes unavailable.

Scenario B — Information disclosure through error messages

An application returns detailed database error messages to the user when an operation fails. An attacker deliberately triggers errors to harvest system information from the error output. The attacker uses the exposed information to craft a targeted SQL injection attack.

Scenario C — Financial state corruption

An attacker interrupts a multi-step financial transaction through network disruption. The transaction order is debit user account, credit destination account, log transaction. The system does not roll back the entire transaction on failure, and the attacker exploits the partial state to drain the user account or trigger duplicate credits.

Detection guidance

• Review application code for exception handling coverage and consistency across all modules.
• Test error responses to verify that no sensitive system information is exposed to users.
• Monitor application logs for patterns of repeated exceptions indicating ongoing attack

attempts.

• Verify that all multi-step transactions implement complete rollback on failure.
• Load test the application to identify resource leaks under sustained exception conditions.
• Check that a global exception handler is in place and functioning as a safety net.

Remediation

• Implement consistent exception handling at every function that can fail, with proper resource

cleanup.

• Deploy a global exception handler to catch and safely handle any unhandled exceptions.
• Replace all user-facing error messages with generic responses and log details internally.
• Add complete rollback logic to all multi-step transactions.
• Deploy rate limiting and resource quotas on endpoints susceptible to abuse.
• Standardize error handling across the entire application using a centralized mechanism.

---

Content derived from works by the OWASP Foundation, licensed under CC BY-SA 4.0 (<https://creativecommons.org/licenses/by-sa/4.0/>). Modifications: Restructured into agent-consumable reference format with added detection and remediation guidance.