Checklist

OWASP Top 10 proactive controls

A checklist based on the OWASP Top 10 Proactive Controls — the security controls every developer should build into every project. Pair this with the Top 10 risks list when scoping a new feature.

47 items
10 sections
Reusable template

Your progress

0 of 47 items complete

complete

Saved in your browser. Sign in to Checksy to share progress with your team.

C1 Define security requirements

Capture security requirements alongside functional requirements
Reference a known standard (ASVS) for the target assurance level
Write abuse cases for each high-value feature
Make security acceptance criteria testable

C2 Leverage security frameworks and libraries

Use a framework's built-in auth, session, CSRF, and templating instead of hand-rolling
Pin framework and library versions
Subscribe to security advisories for each framework in use
Remove unmaintained or end-of-life dependencies

C3 Secure database access

Use parameterized queries everywhere; no string concatenation
Connect with the least-privileged account for the operation
Disable unused database features (xp_cmdshell, file I/O, etc.)
Encrypt sensitive columns at rest where supported
Restrict database network access to known application hosts

C4 Encode and escape data

Encode for the destination context (HTML, attribute, JS, CSS, URL)
Use the framework's auto-escaping templates by default
Avoid `innerHTML` and equivalent unsafe sinks
Escape data placed into log files to prevent log injection

C5 Validate all inputs

Validate server-side, even when the client also validates
Use allow-lists (type, length, range, format) over deny-lists
Reject invalid input rather than trying to clean it
Validate uploaded files for type, size, and content
Validate JSON/XML against a schema

C6 Implement digital identity

Offer multi-factor authentication
Hash passwords with Argon2id, bcrypt, or scrypt
Use a vetted session manager from the framework
Apply NIST 800-63b guidance for password policy
Provide secure account recovery that does not enable takeover

C7 Enforce access controls

Deny by default; allow by explicit policy
Centralize access control checks in one place
Verify object ownership for every request that names an ID
Re-authenticate before sensitive actions (password change, payout)
Log access control denials and alert on bursts

C8 Protect data everywhere

TLS 1.2+ for all external and internal traffic
Classify data and apply encryption matching its sensitivity
Use vetted cryptographic libraries (no custom crypto)
Manage keys in a KMS or secrets manager
Set strict cache headers on sensitive responses

C9 Implement security logging and monitoring

Log authentication, access control, and validation failures
Include who, what, when, and from where in every security event
Send logs to a central system that the app cannot tamper with
Alert on anomalies (login spikes, privilege changes)
Have a tested incident response runbook

C10 Handle all errors and exceptions

Fail closed — deny access when an unexpected error occurs
Show generic error messages to users; full detail only in logs
Catch exceptions at trust boundaries; never swallow silently
Cover error paths in tests, not only happy paths
Roll back partial changes when an operation fails

Markdown source

Copy this and paste it into Checksy to import the checklist.

Show markdown Hide markdown

---
template: true
about: A checklist based on the OWASP Top 10 Proactive Controls — the security controls every developer should build into every project. Pair this with the Top 10 risks list when scoping a new feature.
---

# OWASP Top 10 proactive controls

## C1 Define security requirements

- [ ] Capture security requirements alongside functional requirements
- [ ] Reference a known standard (ASVS) for the target assurance level
- [ ] Write abuse cases for each high-value feature
- [ ] Make security acceptance criteria testable

## C2 Leverage security frameworks and libraries

- [ ] Use a framework's built-in auth, session, CSRF, and templating instead of hand-rolling
- [ ] Pin framework and library versions
- [ ] Subscribe to security advisories for each framework in use
- [ ] Remove unmaintained or end-of-life dependencies

## C3 Secure database access

- [ ] Use parameterized queries everywhere; no string concatenation
- [ ] Connect with the least-privileged account for the operation
- [ ] Disable unused database features (xp_cmdshell, file I/O, etc.)
- [ ] Encrypt sensitive columns at rest where supported
- [ ] Restrict database network access to known application hosts

## C4 Encode and escape data

- [ ] Encode for the destination context (HTML, attribute, JS, CSS, URL)
- [ ] Use the framework's auto-escaping templates by default
- [ ] Avoid `innerHTML` and equivalent unsafe sinks
- [ ] Escape data placed into log files to prevent log injection

## C5 Validate all inputs

- [ ] Validate server-side, even when the client also validates
- [ ] Use allow-lists (type, length, range, format) over deny-lists
- [ ] Reject invalid input rather than trying to clean it
- [ ] Validate uploaded files for type, size, and content
- [ ] Validate JSON/XML against a schema

## C6 Implement digital identity

- [ ] Offer multi-factor authentication
- [ ] Hash passwords with Argon2id, bcrypt, or scrypt
- [ ] Use a vetted session manager from the framework
- [ ] Apply NIST 800-63b guidance for password policy
- [ ] Provide secure account recovery that does not enable takeover

## C7 Enforce access controls

- [ ] Deny by default; allow by explicit policy
- [ ] Centralize access control checks in one place
- [ ] Verify object ownership for every request that names an ID
- [ ] Re-authenticate before sensitive actions (password change, payout)
- [ ] Log access control denials and alert on bursts

## C8 Protect data everywhere

- [ ] TLS 1.2+ for all external and internal traffic
- [ ] Classify data and apply encryption matching its sensitivity
- [ ] Use vetted cryptographic libraries (no custom crypto)
- [ ] Manage keys in a KMS or secrets manager
- [ ] Set strict cache headers on sensitive responses

## C9 Implement security logging and monitoring

- [ ] Log authentication, access control, and validation failures
- [ ] Include who, what, when, and from where in every security event
- [ ] Send logs to a central system that the app cannot tamper with
- [ ] Alert on anomalies (login spikes, privilege changes)
- [ ] Have a tested incident response runbook

## C10 Handle all errors and exceptions

- [ ] Fail closed — deny access when an unexpected error occurs
- [ ] Show generic error messages to users; full detail only in logs
- [ ] Catch exceptions at trust boundaries; never swallow silently
- [ ] Cover error paths in tests, not only happy paths
- [ ] Roll back partial changes when an operation fails

Run this checklist for real

Save your progress, share with your team, and turn this into a reusable template. This helps you track how you improve over time.

Try Checksy More checklists