OWASP Top 10 Proactive Controls: The Ten Developer Habits and How to Adopt Them

Risk lists such as the OWASP Top 10 tell developers what goes wrong, but not what to build instead. The OWASP Top 10 Proactive Controls 2024 is the other half: ten positive practices, C1 to C10, that OWASP describes as techniques every software architect and developer should know and apply from the start of a project. This page keeps OWASP's numbering and names, condenses what each control asks of a development team, adds the first concrete step to take and the review question to ask in a pull request, and maps the controls to the risk list, ASVS 5.0 chapters and NIST SP 800-53. It is for developers, tech leads and AppSec engineers who run developer enablement. For the language-neutral coding practices behind the controls, see the Secure Coding Guide.

Scope note, checked 9 November 2026: the project page says the controls are a starting point for introductory developer training, not a comprehensive standard, and points teams to the OWASP ASVS for full requirements and to maturity models such as OWASP SAMM for the wider process. The 2024 edition links each control to OWASP Top 10 2021 categories and CWE Top 25 entries; the column for the 2025 risk list below is our mapping. The 2024 edition is the latest numbered release; the project site's root now hosts a "Future Top 10" marked as work in progress, which keeps the same ten control titles.

The Top 10 at a glance

Control names are as OWASP publishes them for the 2024 edition. The pull request question column is NHI Mgmt Group's own.

1. Implement Access Control

What OWASP asks: design access control up front, force every request through a check, consolidate the check in one place, deny by default (including when the check itself throws an error, for new accounts and for new features), apply least privilege with just-in-time and just-enough access, and do not hard-code roles. OWASP stresses that authorisation is not authentication and that checks often apply at several layers, such as business logic and database rows.

First step: pick one enforcement point (middleware, policy library or service) and write a test that fails the build when a route is added without it. See the Broken Access Control Prevention Guide and the Authorisation Models Guide.

2. Use Cryptography to Protect Data

What OWASP asks: classify the data you send, process and store; store passwords with a proper password hashing scheme; manage keys through their life cycle; use current transport protocols and tell clients to enforce them; and plan for cryptographic agility. Its "special case" on application secrets is direct: do not store secrets in code or configuration files or pass them through environment variables, and scan repositories for them.

First step: move connection strings, API keys and service account credentials into a secrets manager or workload identity, and turn on secret scanning in the repository. See the Secrets Management Guide and the Cryptographic Key Management Guide.

3. Validate all Input & Handle Exceptions

What OWASP asks: check data for syntactic validity (the expected form) and then semantic validity (acceptable in context, such as a start date before an end date), in that order, before using it. OWASP is explicit that input validation reduces attack surface but must not be the primary defence against XSS or SQL injection: those need parameterised queries and output encoding.

First step: ban string-built queries and shell calls in the linter, and use allow-list validation on structured fields. See the Input Validation and Output Encoding Guide.

4. Address Security from the Start

What OWASP asks: follow design principles that keep applications reasonable to secure: keep it simple, make the right thing easy, do not rely on obscurity, minimise exposed components and design for defence in depth by asking what happens when a component is breached. Build on well-maintained frameworks rather than reimplementing them, keep them updated, and do not fight the framework.

First step: add a lightweight threat model to the design template for any new service or external interface. See the Threat Modelling Guide.

5. Secure By Default Configurations

What OWASP asks: software should start in a secure state without extensive configuration. Its implementation list: least privilege configurations (cloud storage private by default), deny by default with allow lists, scanned container images from a private registry, declarative infrastructure as code rather than manual set-up, encrypted traffic by default, and continuous verification of configuration.

First step: put secure defaults in the infrastructure-as-code modules teams already copy, and add policy checks in the pipeline so drift is caught before deployment. See the Software Liability and Secure by Design Policy Guide.

6. Keep your Components Secure

What OWASP asks: prefer secure features already in your framework over another library; choose libraries by source (official, signed), popularity, activity, maturity, complexity and security testing; keep an inventory with automatically generated SBOMs; monitor continuously for known vulnerabilities; run software composition analysis early; and update as a recurring task.

First step: generate an SBOM in every build and route new critical findings to the owning team's backlog. See the SBOM Guide.

7. Secure Digital Identities

What OWASP asks: follow NIST SP 800-63B for authentication assurance levels (passwords at AAL1, multi-factor at AAL2, cryptographic authenticators at AAL3), secure password requirements, recovery and storage, and choose deliberately between server-side sessions and client-side tokens such as JWTs, with correct cookie attributes. OWASP advises giving identity work to your most capable engineers.

First step: use your identity provider or a vetted framework for login and sessions rather than custom code, and require review by an identity specialist for changes to them. The same discipline applies to non-human callers: API clients and services need scoped, short-lived tokens, not shared static keys. See the JWT Security Guide.

8. Leverage Browser Security Features

What OWASP asks: use HSTS, Content Security Policy, Referrer-Policy, framing controls (X-Frame-Options or CSP frame directives), Permissions Policy and CSRF protections. OWASP calls these opportunistic: the server cannot verify that a browser honours them, so they add to server-side controls and never replace them.

First step: set the headers centrally at the framework or edge layer and check them in CI. See the Security Headers Guide and the Content Security Policy Guide.

9. Implement Security Logging and Monitoring

What OWASP asks: log events that suggest malicious behaviour (out-of-range values, changes to fields that should not be modifiable, server-side access-control violations) and treat them as high severity; prevent log injection by encoding; never log passwords, session IDs, card numbers or national identifiers; protect log integrity; and forward logs to a central service.

First step: adopt a shared event vocabulary for authentication and authorisation failures so the SOC can alert on them without per-application parsing. See the JWT and Session Tokens in Code and Logs Guide.

10. Stop Server Side Request Forgery

What OWASP asks: prevent attackers from making the server send requests on their behalf, because those requests carry the server's identity. Controls: input validation, an allow list for any outbound target, secure XML parser configuration to prevent XXE, and care with Unicode and other character transformations.

Evidence: in the Capital One breach, an SSRF made a misconfigured firewall return its cloud role's temporary credentials from the instance metadata endpoint, and those credentials were used to copy data from storage buckets. The lesson is that SSRF is an identity problem: the server's machine credentials are the prize.

First step: route outbound fetches through one allow-listed client and require token-based instance metadata access where your cloud offers it (IMDSv2 on AWS, for example). See the SSRF Prevention Guide.

Mapping to OWASP and NIST

The ASVS 5.0 and Top 10:2025 columns are NHI Mgmt Group mappings, based on the chapter names in our OWASP ASVS Guide and the category names in our OWASP Top 10 Guide. SP 800-53 IDs were checked against Rev. 5.

In NIST CSF 2.0 terms the whole list supports PR.PS-06, secure software development practices integrated and monitored, and C1 supports PR.AA-05 on access permissions.

Where to start

1. Use the list for training, ASVS for requirements. Teach C1 to C10 in onboarding; set testable requirements from ASVS. See the Developer Security Training Programme Guide.
2. Start with the controls that remove whole classes. In our experience C1 (one enforcement point), C3 (parameterised queries) and C2 (secrets out of code) give the largest early reduction because each closes a category rather than individual bugs.
3. Turn each control into a paved road. A shared library, template or pipeline check for every control, so the secure way is the default way, which is OWASP's own "make it easy to do the right thing" principle.
4. Add the ten pull request questions to the review template. Reviewers answer only the ones the change touches.
5. Measure adoption, not attendance. Track the share of services using the central authorisation check, secrets found in repositories per month, services emitting the shared security event vocabulary, and the age of the oldest critical dependency finding.
6. Codify it. Put the controls into your Secure Coding Standard Template and review them each year against the latest OWASP edition.

Standards and references

• OWASP: Top 10 Proactive Controls 2024
• OWASP: Proactive Controls project repository
• OWASP: Application Security Verification Standard
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Secure Coding Guide · OWASP Top 10 Guide · OWASP ASVS Guide · Application Security Guide · OWASP SAMM Guide