OWASP Annotated Application Security Verification Standard
latest
Browse by chapter:
v1 Architecture, design and threat modelling
v2 Authentication verification requirements
v3 Session management verification requirements
v4 Access control verification requirements
v5 Malicious input handling verification requirements
v6 Output encoding / escaping
v7 Cryptography at rest verification requirements
v8 Error handling and logging verification requirements
v9 Data protection verification requirements
v10 Communications security verification requirements
v11 HTTP security configuration verification requirements
v12 Security configuration verification requirements
v13 Malicious controls verification requirements
v14 Internal security verification requirements
v15 Business logic verification requirements
v16 Files and resources verification requirements
v17 Mobile verification requirements
v18 Web services verification requirements
v19 Configuration
Browse by level:
Level 1: Opportunistic
Level 2: Standard
Level 3: Advanced
1.1 All components are identified
1.2 All dependencies are identified
1.3 A high-level architecture as been defined
1.4 All components are defined
1.5 All dependant components are defined
1.6 A STRIDE threat model has been produced
1.7 Central implementation for security controls
1.8 Components are segregated
1.9 Clear separation between data, controller and display
1.10 Client side logic does not contain secrets
2.1 Principle of complete mediation
2.2 Password fields
2.4 Server side enforcement
2.6 Fails securely
2.7 Allows for strong passwords
2.8 All account identity authentication functions are secure
2.9 All credential changes are secure
2.12 All authentication decisions are logged
2.13 Account passwords are salted properly
2.16 Strongly encrypted transport
2.17 No clear text passwords
2.18 No username enumeration
2.19 No default passwords
2.20 Protects against brute force attacks
2.21 External service credentials are encrypted and protected
2.22 Password recovery is well implemented
2.23 Password recovery can not be used to lock out users
2.24 No “secret” questions
2.25 Supports configuration to disallow previous passwords
2.26 Sensitive operations are sufficiently protected
2.27 Block common or weak passwords / passphrases
2.28 Authentication success or failure should take equal time
2.29 Secrets are not included in the source code
2.30 Use a proven secure authentication mechanism
2.31 Protects against username & password disclosure
2.32 Admin is not accessible for untrusted parties
3.1 Uses default session management
3.2 Sessions are invalidated on user log out
3.3 Session times out after inactivity
3.4 Session has absolute timeout
3.5 Shows logout link
3.6 Does not disclose session id
3.7 Session id is changed on login
3.10 Session ids may only come from framework
3.11 Session tokens are sufficiently long and random
3.12 Session cookies have appropriately restricted paths
3.16 Does not permit duplicate concurrent user sessions from different machines
3.17 User can see and terminate all his sessions
3.18 User is prompted for session termination on password change
4.1 Authorisation of functions and services
4.4 Authorisation of direct object references
4.5 Disabled directory browsing
4.8 Access controls fail securely
4.9 Access control rules are enfoced server side
4.10 User and data attributes and policy information cannot be manipulated unauthorized
4.11 Access controls are enforced on the server side
4.12 Has centralized mechanism for access to protected resources
4.13 Protects against CSRF
4.14 Access control decisions and failed decisions are logged
4.15 Protects against fraud
4.16 Protects against parameter tampering
5.1 Buffer overflows
5.3 Rejects invalid input
5.5 Input validation or encoding is performed and enforced on the server side.
5.6 One input validation control per type of accepted data
5.10 SQL Injection
5.11 LDAP Injection
5.12 OS Command Injection
5.13 XXE
5.14 XML Injection
5.15 TODO
5.16 HTML escaping
5.17 Protected against malicious automatic binding
5.18 Defends against HTTP parameter pollution attacks
5.19 Output encoding/escaping has a single security control per type
5.20 Structured data is strongly typed and validated with a schema
5.21 Unstructured data is sanitized
5.22 Untrusted HTML is sanitized
5.23 Auto escaping technology always applies HTML sanitization
5.24 DOM writes use safe JavaScript methods
5.25 JSON is properly parsed by browser
5.26 Data is cleared from client storage on session termination
7.2 Crypto fails securely
7.6 Random numbers, file names, GUIDs and strings are sufficiently random
7.7 Crypto modules have been validated against FIPS 140-2 or equivalent
7.8 Crypto modules operate in their approved mode
7.9 Policy for cryptographic key management exists and is enforced
7.11 Cryptographic processes are isolated
7.12 PII is encrypted at rest and protected during communication
7.13 Keys and secrets are zeroed when destroyed
7.14 Secrets are replaceable and placed at installation
7.15 Random numbers are sufficiently random even under load
8.1 Information leakage
8.2 Error handling is performed on trusted devices
8.3 Logging controls are implemented on the server
8.4 Error handling logic denies access by default
8.5 Security relevant success and failure events are loggable by controls
8.6 Log events are complete
8.7 Events that include untrusted data will not be executed
8.8 Security logs are protected
8.9 Single application-level logging implementation
8.10 Application log does not include sensitive data
8.11 A sufficiently advanced log analysis tool is available
8.12 Logs are stored differently and rotated
9.1 Sensitive data does not get cached
9.2 Sensitive data is identified and access policy exists and is enforced
9.3 Sensitive data does not get sent in the URL
9.4 Temporary client caches of sensitive data are properly cleaned up
9.5 Temporary server caches of sensitive data are properly cleaned up
9.6 Sensitive data can be removed after required retention period
9.7 Minimal parameters are sent to untrusted systems
9.8 Abnormal behaviour is detectable
9.9 Client side storage does not contain secrets
9.10 Accessing sensitive data is logged
9.11 Sensitive data is rapidly sanitized from memory
10.1 TLS chain is valid
10.3 TLS is used for all relevant connections
10.4 Backend TLS connection failures are logged
10.5 Client certificates are built and verified correctly
10.6 Connections to relevant external systems are authenticated
10.8 Single standard well-configured TLS implementation is used
10.10 Certificate pinning is used correctly
10.11 Strict Transport Security is used correctly
10.12 URL is submitted to HSTS preload lists
10.13 Forward secrecy ciphers are used
10.14 Certification revocation is enabled and configured
10.15 Strong certificate hierarchy
10.16 TLS settings are current
11.1 Only defined HTTP Request methods are accepted
11.2 Every HTTP Response contains a Content-Type header with safe character set
11.3 Trusted HTTP headers are authenticated
11.4 X-Frame-Options is used correctly
11.5 X-Content-Type-Options is used correctly
11.6 HTTP headers in Requests and Responses contain only printable ASCII
11.7 Content-Security-Policy is used correctly
11.8 X-XSS-Protection is used correctly
13.1 No malicious code in custom code
13.2 Code, libraries, executables and configuration files are verfied
15.1 Appropriately uses a trusted environment
15.2 Does not allow spoofed high value transactions
16.1 Safe from unsafe redirects
16.2 Safe from path traversal
16.3 Anti-virus scanning
16.4 Safe from local file inclusion attacks
16.5 Safe from remote file inclusion attacks
16.6 Resource sharing
16.7 Untrusted files are stored outside the webroot
16.8 Deny access to resources or systems outside web or app server
16.9 Does not execute uploaded data from untrusted sources
17.1 App verifies SSL certificates
17.2 App does not use UDID values as security controls
17.3 App protects sensitive data
17.4 App does not use SQLite for sensitive data
17.5 App does not have Secret credentials hard-coded in executable
17.6 App protects against auto-snapshot information leakage
17.7 App cannot be run on a jailbroken or rooted device
17.8 App session timeout is of a reasonable value
17.9 App requires appropriate permissions and resources
17.10 App crash log does not contain sensitive data
17.11 App binary has been obfuscated
18.1 Web Service client and server use same encoding
18.2 Web Service admin is limited to admins
18.3 XML or JSON schemas are used properly
18.4 Input is size limited
18.5 SOAP services comply to WS-I Basic Profile
18.6 Session based authentication and authorization is used
18.7 REST service is not vulnerable to CSRF
18.8 REST service verifies Content-Type
18.9 Message payload is signed
18.10 No alternative (insecure) access paths
19.1 Components are stripped, up-to-date and securely configured
19.2 Communication between components is encrypted
19.3 Communication between components is authenticated with least privileges
19.4 Deployments are adequately sandboxed, containerized or isolated
19.5 Deployment processes are secure
19.6 Admins can verify integrity of configuration
19.7 Application components are signed
19.8 Thrid party components come from trusted repos
19.9 Security flags are enabled
OWASP Annotated Application Security Verification Standard
Docs
»
v19 Configuration
»
19.7 Application components are signed
Edit on GitHub
19.7 Application components are signed
ΒΆ
Verify that all application components are signed.
Levels: 3
Read the Docs
v: latest
Versions
latest
Downloads
pdf
htmlzip
epub
On Read the Docs
Project Home
Builds
Free document hosting provided by
Read the Docs
.