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