OWASP Top 10 Proactive Controls: the C1-C10 catalog, explained

The OWASP Top 10 Proactive Controls is a catalog of ten secure-coding practices maintained by the OWASP Foundation, built for developers rather than auditors. Where the better-known OWASP Top 10 documents the vulnerability categories most likely to show up in a web application, Proactive Controls documents the other side of that coin: the practices a developer can build into the code from the start to avoid those categories ever appearing. OWASP's own index page for the project describes proactive controls as "a catalog of better practices, a set of items developers can embrace and implement in their code bases to avoid many common security issues."

Who it's for

The project's "About this Project" page is explicit about audience and scope: it is "primarily written for developers," though "development managers, product owners, Q/A professionals, program managers, and anyone involved in building software can also benefit from this document." It also sets honest expectations about depth, describing itself as "a starting point rather than a comprehensive set of techniques and practices" — a foundational awareness document, not a full requirements specification.

The 10 controls (C1-C10)

OWASP's own Top 10 index page lists these controls, in this order, in the current (2024) edition:

#	Control	What it covers
C1	Implement Access Control	Enforcing who may access which resource, consistently across every layer (business logic, database rows, every API and UI path)
C2	Use Cryptography to Protect Data	Protecting sensitive data in storage and transit, especially data covered by privacy or financial-data rules
C3	Validate all Input & Handle Exceptions	Treating all input as untrusted and failing safely when it's malformed
C4	Address Security from the Start	Designing a secure architecture during initial design rather than remediating after the fact
C5	Secure By Default Configurations	Shipping and deploying with secure defaults rather than requiring a user to opt into safety
C6	Keep your Components Secure	Tracking and patching the libraries and frameworks an application depends on
C7	Secure Digital Identities	Authentication, session management and identity assurance
C8	Leverage Browser Security Features	Using browser-enforced controls (headers, cookie flags, CSP and similar) as a defense layer
C9	Implement Security Logging and Monitoring	Recording and actively reviewing security-relevant events during runtime
C10	Stop Server Side Request Forgery	Preventing a server from being coerced into making requests on an attacker's behalf

OWASP's own navigation also shows archived 2014, 2016 and 2018 editions of this project, plus — as checked for this guide — a work-in-progress future edition, so this exact ordering and the C10 entry (new in the 2024 edition) are not guaranteed to be stable across releases; a team citing a specific control number in internal documentation should link the specific edition rather than just "the OWASP Proactive Controls."

A closer look at four of the ten

C1, Implement Access Control, is framed around a layering problem as much as a single check: OWASP's own C1 page notes access control "often applies on multiple levels, e.g., given an application with a database backend, it applies both on the business logic level as well as on a database row level," and that every path into the application — API or UI — "must be aligned, i.e., use the same access control checks." It also distinguishes Role-Based Access Control (permissions tied to roles) from Attribute-Based Access Control (permissions evaluated from arbitrary user, resource and environment attributes), and warns that re-engineering access control after the fact, once a pattern is chosen, is "often difficult and time-consuming."

C6, Keep your Components Secure, is the control that maps most directly onto supply-chain security work SoftWSP already covers in its firmware SBOM and SBOM minimum elements guides. OWASP's own C6 page recommends maintaining Software Bills of Materials (SBOMs) and using continuous monitoring tooling (it names OWASP's own Dependency-Track project as an example) to detect publicly disclosed vulnerabilities in dependencies automatically, rather than relying on a one-time audit at release time.

C9, Implement Security Logging and Monitoring, separates two related but distinct activities. OWASP's own page frames logging as something "most developers already use for debugging and diagnostic purposes," with security logging as the same concept applied specifically to security-relevant runtime events, while monitoring is the live, ideally automated, review of those logs with the explicit goal of detecting and responding to incidents — logging without review does not satisfy C9 on its own.

C10, Stop Server Side Request Forgery, is the newest addition and the only control named after a specific attack rather than a defensive practice. OWASP's own page distinguishes it from ordinary injection: "while Injection Attacks typically target the victim server itself, Server-Side Request Forgery (SSRF) attacks try to coerce the server to perform a request on behalf of the attacker," letting an attacker reuse the server's own network position and credentials against internal systems the attacker could not otherwise reach directly.

Where it fits next to the rest of the OWASP catalog

Proactive Controls, ASVS and SAMM answer three different questions and are designed to be used together rather than as alternatives: Proactive Controls teaches a developer what to do while writing code; ASVS gives a verifiable, testable requirements checklist to build or audit an application against; SAMM assesses and matures an organization's software security process over time, independent of any one application. A device maker or firmware team already working through SoftWSP's CRA or IEC 62443-4-1 secure development lifecycle guidance can treat Proactive Controls as the developer-facing training layer underneath those program-level requirements, not a replacement for them.

A workable starting point

1. Use it for onboarding, not auditing. Proactive Controls is written to teach practices, not to generate a pass/fail compliance report — use ASVS for that.
2. Start with C1 and C3. Access control and input validation remain the controls most directly tied to the highest-impact vulnerability categories in the OWASP Top 10.
3. Treat C6 as a continuous process, not a release gate. New vulnerabilities are disclosed in existing dependencies constantly; a one-time dependency audit at ship time misses everything disclosed afterward.
4. Re-check the edition you're citing. OWASP maintains multiple archived editions side by side; confirm whether your team's internal references point at the 2018 or 2024 control numbering before relying on a specific "Cx" label in documentation.

SoftWSP's device and firmware security reviews check dependency and component hygiene (C6) and logging/monitoring posture (C9) as part of a broader firmware security assessment: see device & firmware security services.

This guide summarises a public OWASP community project; it does not constitute legal or compliance advice.