Level 2: Standard¶

1.1 All components are identified
1.2 All dependencies are identified
1.3 A high-level architecture as been defined
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.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.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.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.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.9 Policy for cryptographic key management exists and is enforced
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
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.6 Log events are complete
8.7 Events that include untrusted data will not be executed
8.10 Application log does not include sensitive data
9.1 Sensitive data does not get cached
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.7 Minimal parameters are sent to untrusted systems
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.6 Connections to relevant external systems are authenticated
10.11 Strict Transport Security is used correctly
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
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.9 App requires appropriate permissions and resources
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