Checklist

OWASP input validation checklist

A checklist based on the OWASP Input Validation Cheat Sheet. Use this when reviewing how the app accepts data from users, files, APIs, and other untrusted sources.

35 items
8 sections
Reusable template

Your progress

0 of 35 items complete

complete

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

Where to validate

All input is validated on the server, even when the client also validates
Validation runs at the trust boundary, before business logic
Inputs from "internal" services that cross trust zones are also validated
Decoded values (URL-decoded, base64-decoded) are validated, not raw

Validation strategy

Use allow-lists of expected values, not deny-lists of bad values
Reject invalid input outright; do not try to sanitize it back to valid
Validate type, length, range, format, and character set
Canonicalize input (Unicode normalization, path normalization) before validation
Use a single canonical character set (UTF-8) end-to-end

Strings and identifiers

Enforce a maximum length on every string field
Restrict character set where possible (ASCII, alphanumeric, etc.)
Validate emails, URLs, phone numbers with a vetted parser
Reject strings containing null bytes or control characters
Validate identifiers against the actual catalog, not just regex

Numbers, dates, and ranges

Parse numbers and dates with strict, locale-independent parsers
Reject values outside the documented business range
Reject NaN, infinity, and negative zero where they are not meaningful
Use integer types sized to the domain; avoid silent truncation

Structured data (JSON, XML, YAML)

Validate against a schema (JSON Schema, XSD, etc.)
Set limits on nesting depth, array length, and total size
Disable external entity resolution (XXE) for XML parsers
Disable arbitrary type instantiation in YAML loaders
Reject unknown fields when strict input is required

File uploads

Restrict allowed MIME types via allow-list and detect by content, not extension
Cap file size and total upload size per request
Store uploads outside the web root
Generate new filenames; never use user-supplied paths
Scan uploads for malware before further processing

URLs and redirects

Validate URLs against an allow-list of schemes (https only, typically)
Validate redirect targets against an allow-list of hosts
Block private and link-local IP ranges when the app fetches URLs (SSRF)
Resolve hostnames once and use the resolved IP for the request

Output considerations

Validated input is still encoded for the destination context (HTML, SQL, shell)
Validation does not replace parameterized queries or templating
Errors return generic messages; details go to the log

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 Input Validation Cheat Sheet. Use this when reviewing how the app accepts data from users, files, APIs, and other untrusted sources.
---

# OWASP input validation checklist

## Where to validate

- [ ] All input is validated on the server, even when the client also validates
- [ ] Validation runs at the trust boundary, before business logic
- [ ] Inputs from "internal" services that cross trust zones are also validated
- [ ] Decoded values (URL-decoded, base64-decoded) are validated, not raw

## Validation strategy

- [ ] Use allow-lists of expected values, not deny-lists of bad values
- [ ] Reject invalid input outright; do not try to sanitize it back to valid
- [ ] Validate type, length, range, format, and character set
- [ ] Canonicalize input (Unicode normalization, path normalization) before validation
- [ ] Use a single canonical character set (UTF-8) end-to-end

## Strings and identifiers

- [ ] Enforce a maximum length on every string field
- [ ] Restrict character set where possible (ASCII, alphanumeric, etc.)
- [ ] Validate emails, URLs, phone numbers with a vetted parser
- [ ] Reject strings containing null bytes or control characters
- [ ] Validate identifiers against the actual catalog, not just regex

## Numbers, dates, and ranges

- [ ] Parse numbers and dates with strict, locale-independent parsers
- [ ] Reject values outside the documented business range
- [ ] Reject NaN, infinity, and negative zero where they are not meaningful
- [ ] Use integer types sized to the domain; avoid silent truncation

## Structured data (JSON, XML, YAML)

- [ ] Validate against a schema (JSON Schema, XSD, etc.)
- [ ] Set limits on nesting depth, array length, and total size
- [ ] Disable external entity resolution (XXE) for XML parsers
- [ ] Disable arbitrary type instantiation in YAML loaders
- [ ] Reject unknown fields when strict input is required

## File uploads

- [ ] Restrict allowed MIME types via allow-list and detect by content, not extension
- [ ] Cap file size and total upload size per request
- [ ] Store uploads outside the web root
- [ ] Generate new filenames; never use user-supplied paths
- [ ] Scan uploads for malware before further processing

## URLs and redirects

- [ ] Validate URLs against an allow-list of schemes (https only, typically)
- [ ] Validate redirect targets against an allow-list of hosts
- [ ] Block private and link-local IP ranges when the app fetches URLs (SSRF)
- [ ] Resolve hostnames once and use the resolved IP for the request

## Output considerations

- [ ] Validated input is still encoded for the destination context (HTML, SQL, shell)
- [ ] Validation does not replace parameterized queries or templating
- [ ] Errors return generic messages; details go to the log

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