Application Security Audit Checklist: 100+ Items (2026)

An application security audit is a systematic review of your software to identify security vulnerabilities, misconfigurations, and design weaknesses before they can be exploited. This checklist covers every major area of application security for web applications, APIs, and backend systems.

Use this checklist for: internal security reviews, pre-launch audits, compliance preparation (SOC 2, ISO 27001, PCI-DSS), or as a structured guide for penetration test scoping.

1. Reconnaissance & Asset Inventory

Before testing, establish scope and map all attack surface:

Enumerate all application endpoints (authenticated and unauthenticated)
Document all API endpoints (REST, GraphQL, SOAP, gRPC)
Identify all third-party integrations and external data flows
Map all user roles and privilege levels
Catalog all sensitive data types processed (PII, financial, health records)
Identify all deployment environments (prod, staging, dev) and their exposure
List all technology stack components (languages, frameworks, databases, cloud services)

2. Static Application Security Testing (SAST)

Analyze source code for vulnerabilities without executing the application:

Injection Flaws

SQL injection (parameterized queries used everywhere)
Second-order SQL injection (DB-sourced data also parameterized)
Command injection (no unsanitized user input passed to shell)
LDAP injection
XPath/XML injection
Template injection (SSTI in Jinja2, Twig, Freemarker, etc.)
Code injection (eval(), exec(), system() with user input)

Cross-Site Scripting (XSS)

Reflected XSS — all input properly encoded on output
Stored XSS — all database-sourced values encoded when rendered
DOM-based XSS — client-side sinks (innerHTML, document.write) don’t accept user data
Content-Security-Policy header configured to block inline scripts

Sensitive Data Handling

No hardcoded secrets (passwords, API keys, tokens) in source code
No secrets in git history (use git secret scan or truffleHog)
Environment variables used for all credentials
.env files excluded from version control (.gitignore)
No sensitive data in log statements

Authentication Code

Password hashing uses bcrypt, scrypt, or Argon2 (not MD5, SHA1, or SHA256 alone)
Session tokens are cryptographically random (minimum 128 bits)
Password reset tokens are single-use and expire after 15 minutes
Account lockout logic cannot be bypassed
OAuth/OIDC implementation follows spec correctly (state parameter, PKCE)

Authorization Logic

Authorization checks performed server-side on every request
Insecure Direct Object Reference (IDOR) — resource IDs cannot be guessed or tampered
Privilege escalation paths reviewed (can USER access ADMIN functions?)
Mass assignment protection (no unfiltered JSON binding to model properties)

3. Dynamic Application Security Testing (DAST)

Test the running application for vulnerabilities:

Authentication & Session

Brute force protection on login (rate limiting, account lockout, CAPTCHA)
Session tokens not exposed in URLs
Session tokens rotated after login (prevents session fixation)
Logout invalidates the session server-side
Concurrent session limits enforced where required
MFA available and enforced for privileged accounts

Authorization

Horizontal privilege escalation — can User A access User B’s data?
Vertical privilege escalation — can a regular user access admin functions?
IDOR testing on all resource endpoints with incremental/predictable IDs
Function-level access control — test all API endpoints without authentication

Input Validation

SQL injection (manual + automated — use sqlmap for depth)
XSS in all input fields, headers, and URL parameters
File upload security — malicious file types rejected, uploaded files not executed
XXE (XML External Entity) in XML-accepting endpoints
SSRF (Server-Side Request Forgery) — URL parameters that fetch remote content
Open redirect — redirect parameters cannot point to external domains

Business Logic

Price/quantity tampering in e-commerce flows
Workflow bypass — can step 3 be accessed before completing steps 1 and 2?
Race conditions — simultaneous requests to transfer money, use discounts, etc.
Negative values where only positive are expected

4. API Security

APIs require dedicated testing — standard web app testing misses API-specific flaws:

Authentication required on all non-public API endpoints
API keys not exposed in client-side code or URLs
Rate limiting on all API endpoints (especially auth endpoints)
CORS policy restrictive — Access-Control-Allow-Origin not set to * for authenticated endpoints
HTTP methods restricted — PUT/DELETE only available where needed
Excessive data exposure — API responses don’t return fields the client doesn’t need
Mass assignment — POST/PUT body filtering enforced
GraphQL: introspection disabled in production; depth and complexity limits set
API versioning — old versions deprecated and decommissioned

5. Cryptography

All data in transit encrypted with TLS 1.2 or higher
TLS 1.0 and 1.1 disabled
Weak cipher suites disabled (RC4, 3DES, export ciphers)
HSTS header set (Strict-Transport-Security: max-age=31536000; includeSubDomains)
Certificate validity and chain verified
Data at rest encrypted for sensitive fields (PII, payment data, credentials)
Encryption keys stored separately from encrypted data
No use of MD5 or SHA1 for security purposes
Random number generation uses a cryptographically secure source (CSPRNG)

6. Security Headers

Check all HTTP response headers:

Header	Required Value
`Content-Security-Policy`	Restrictive policy blocking inline scripts
`Strict-Transport-Security`	`max-age=31536000; includeSubDomains`
`X-Content-Type-Options`	`nosniff`
`X-Frame-Options`	`DENY` or `SAMEORIGIN`
`Referrer-Policy`	`strict-origin-when-cross-origin`
`Permissions-Policy`	Restrict camera, microphone, geolocation
`Cache-Control`	`no-store` for sensitive pages

All of the above headers present and correctly configured
No server version disclosure (Server:, X-Powered-By: headers removed)
No internal path disclosure in error messages

7. Software Composition Analysis (SCA)

All direct dependencies scanned for known CVEs
All transitive (indirect) dependencies scanned
No dependencies with critical/high CVEs in production
Dependency lockfiles committed (package-lock.json, Gemfile.lock, etc.)
Automated SCA in CI/CD pipeline
Process for triaging and patching vulnerable dependencies
Open-source license compliance reviewed (GPL, AGPL implications)
Abandoned/unmaintained packages identified and evaluated

8. Infrastructure & Deployment

9. Cloud Security (if applicable)

S3 buckets (or equivalent) not publicly readable unless intentional
IAM roles follow least-privilege principle
No wildcard permissions (*) on IAM policies
Cloud storage access logs enabled
VPC properly segmented — application, database, management layers separated
Database not directly internet-accessible
Security groups/firewall rules reviewed and tightened
Cloud provider security score/recommendations reviewed (AWS Trusted Advisor, GCP Security Command Center)

10. Logging & Monitoring

Authentication events logged (login, logout, failure, MFA)
Authorization failures logged
All admin actions logged
Logs stored securely and tamper-proof
Logs do NOT contain sensitive data (passwords, full credit card numbers, tokens)
Alerting configured for anomalous activity (brute force, unusual access patterns)
Log retention meets compliance requirements
Incident response plan documented and tested

11. Third-Party & Supply Chain

Third-party scripts loaded with Subresource Integrity (SRI) hashes
CDN providers reviewed for security posture
Third-party API keys scoped to minimum required permissions
Vendor security questionnaires completed for data processors
Build pipeline dependencies pinned to specific versions/hashes
CI/CD environment isolated from production systems

Audit Severity Scoring

Use this severity scale for findings:

Severity	Criteria	Remediation SLA
Critical	Remote code execution, auth bypass, mass data exposure	24 hours
High	SQLi, stored XSS, IDOR exposing PII, SSRF	7 days
Medium	Reflected XSS, missing security headers, outdated dependencies	30 days
Low	Information disclosure, missing rate limiting	90 days
Informational	Best practice deviations with low exploitability	Next sprint

Automating This Checklist

Many items on this checklist can be automated:

SAST scan covers: injection, XSS, hardcoded secrets, crypto issues, auth logic → Run a SAST scan
DAST scan covers: authentication, session management, headers, IDOR, input validation → Run a DAST scan
SCA covers: vulnerable dependencies, license compliance
Manual review required for: business logic flaws, complex authorization, design issues

For a complete automated + manual security audit, contact the Offensive360 team.