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