OWASP Top 10:2025 Web Application Security Checklist

Start with the risk categories, not a checkbox promise

OWASP Top 10:2025 lists ten broad areas, including broken access control, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, software or data integrity failures, security logging and alerting failures, and mishandling exceptional conditions. These categories help teams organise security conversations and identify weak assumptions. They do not prove that an application is secure when each heading is mentioned in a project plan.

Map the categories to the actual system. Identify users, roles, data, trust boundaries, external providers, administrative functions and high-impact workflows. A customer portal, CRM, mobile API and internal dashboard have different exposure and business consequences. Security controls should follow the risks and the data the application handles.

Enforce authorisation at every trusted boundary

Broken access control remains a high-impact application risk. Hiding a button in the browser is not authorisation. The server must verify whether the current user can perform the requested action on the specific record, tenant, field and workflow. Test object-level access by trying to retrieve, update, export or delete another user's records through direct API requests.

Use deny-by-default decisions and centralise policy checks where possible. Review both role-level and object-level permissions. Background jobs, file downloads, search endpoints and administrative routes need the same discipline as ordinary page views. When an organisation uses multiple tenants, tenant context must be validated at the server boundary and enforced in each data access path.

Reduce configuration and software supply-chain risk

Development, staging and production environments should not share broad credentials or debug settings. Disable unnecessary endpoints, restrict administrative access, protect backups, apply security headers and keep infrastructure defaults under review. Secrets should be stored outside source code and exposed only to the processes that need them.

Third-party libraries, build actions, container images and packages are part of the software supply chain. Maintain an inventory of dependencies, review update signals and remove packages that are no longer needed. Pin workflow dependencies to trusted immutable versions where appropriate, verify artifacts and restrict who can modify release pipelines. Keep a process for investigating vulnerable components rather than depending on one scan at build time.

Protect identity, sessions and sensitive data

Authentication should use well-understood protocols and secure password handling. Multi-factor authentication may be appropriate for privileged or sensitive workflows. Protect session cookies, rotate or revoke sessions when access changes and make account recovery resistant to abuse. Rate-limit login and recovery flows without creating unnecessary lockouts for legitimate users.

Classify sensitive data and collect only what the product needs. Encrypt data in transit and at rest where the risk and platform require it, manage keys carefully and avoid putting credentials or personal information in logs. Access control must continue to apply to cached data, exports, search indexes, object storage and backups. Encryption does not compensate for a system that grants the wrong person access.

Prevent injection and unsafe input handling

Validate input at system boundaries and use parameterised database queries. Encode output according to its context, such as HTML, JavaScript or URL. Avoid unsafe deserialisation and validate uploaded file type, size and content according to the business need. Never assume that a value is safe because it came from a form, an API client or another internal service.

For file handling and document workflows, isolate parsing where possible, enforce resource limits and avoid executing uploaded content. For server-side requests, restrict destinations and validate resolved addresses to reduce server-side request forgery risks. Tests should include malformed, oversized and unexpected inputs, not only happy-path values.

Make failures visible without leaking details

Applications need logs that help operators detect and investigate suspicious activity. Record security-relevant events such as failed access decisions, role changes, privileged actions and unusual authentication patterns. Protect log access, use consistent timestamps and retain events according to a documented policy. Do not log passwords, tokens, private keys or full sensitive request bodies.

Handle exceptions deliberately. Return useful, non-sensitive messages to users while keeping diagnostic detail in controlled server logs. Define alerts for patterns that matter and assign an owner to review them. A log that nobody monitors is not an effective detection control.

Test the design and the implementation

Threat modelling asks how an attacker could misuse a workflow before it is built. Code review, dependency scanning, static analysis, dynamic testing and manual security testing provide different kinds of evidence. Use them together based on risk. A security test must have a written scope and explicit authorisation; production systems and third-party environments should never be probed without permission.

Prioritise findings by exploitability, data sensitivity and business impact. Agree remediation, retest fixes and record accepted risks with an accountable owner. Repeat the process after major changes to identity, payments, file handling, integrations or tenancy. Security is a lifecycle practice rather than a one-time certificate.

GrapeCrux can help teams review application flows, integrate security checks into QA, improve access-control test coverage and prepare practical remediation backlogs. Any penetration testing or active security assessment requires a separately agreed authorised scope.

OWASP Top 10:2025: practical security checks for modern web applications