Security Acceptance Criteria
Existing user stories will typically include acceptance criteria in the form of security requirements more frequently. Examples are provided in the following.
Application Architecture and Design
Information Security evaluates current data and process flow diagrams for risk.
System and application components are hardened to Information Security standards and tested for vulnerabilities. All critical and high vulnerabilities will be fixed before release.
Compliance and Information Security Data Handling Requirements separate components.
Authentication, Authorization, and Accounting
All sites and resources except public ones require authentication.
The application does not fully out credentials forms. Pre-populating a form may save credentials in plaintext or a reversible format.
All server authentication controls are enforced.
Every authentication control fails safely to prevent attackers from logging in.
Logging all authentication decisions does not save session identifiers or passwords. This should include security investigation metadata requests.
Information cannot be enumerated by login, password reset, or forgot account.
Make sure the application framework and components don’t utilize default passwords like “admin/password”.
Credential testing, brute forcing, and account lockout attacks are prevented by anti-automation.
All authentication credentials for external services are encrypted and saved securely.
Soft and hard account lockouts are not mutually exclusive. An account soft locked out by a brute force attack should not reset the hard lock.
Credential testing, brute forcing, and account lockout attacks are prevented by anti-automation.
Shared knowledge-based questions (sometimes called “secret questions”) must conform to privacy rules and be robust enough to prevent fraudulent account recovery.
A customizable number of prior passwords can be blocked.
Successful and unsuccessful authentication challenges should have the same average response time.
Secrets, API keys, and passwords should not be in source code or online repositories.
Untrusted parties cannot access administrative interfaces.
Access Control
All access control decisions, including failures, are logged.
The program properly enforces context-sensitive authorization to prevent parameter tampering.
Lower-value systems have step up or adaptive authentication, while high-value applications have segregation of duties to implement anti-fraud rules based on application risk and historical fraud.
For each protected resource, a centralized method (including libraries that call external authorization services) protects access.
Ensure end users cannot change user and data attributes and policy information utilized by access controls without authorization.
Directory browsing is blocked until requested. Thumbs.db,.DS_Store,.git, and.svn folder metadata should not be discovered or disclosed by programs.
Input Validation Handling
Client storage like the browser DOM is cleaned of authenticated data once the session ends.
Browsers utilize JSON.parse to parse JSON on the client. Do not parse JSON on the client with eval().
Data transmitted between DOM contexts employs safe JavaScript methods like.innerText and.val.
HTML sanitization should be enabled for auto-escaping template technology if UI escaping is disabled.
HTML sanitizers clean up untrusted HTML from WYSIWYG editors and manage it according to input validation and encoding tasks.
When sanitizing unstructured data, characters that may be damaging in context are escaped, such as natural names with Unicode or apostrophes (e.g., ねこ or O’Hara).
Credit card numbers, telephone numbers, and associated fields like suburbs and zip or post codes are tightly typed and validated against a schema that includes allowable characters, length, and pattern.
All input data, including HTML form fields, REST calls, query parameters, HTTP headers, cookies, batch files, RSS feeds, etc., is validated using positive validation (whitelisting), then grey listing (eliminating known bad strings), or rejecting bad inputs.
Check for HTTP parameter pollution defenses, especially if the application framework does not distinguish between request parameters (GET, POST, cookies, headers, environment, etc.).
Security-sensitive fields like “account Balance”, “role” and “password” should be safeguarded against malicious automated binding if the application framework supports automatic bulk parameter assignment (variable binding) from the incoming request to a model.
Ensure that all string variables in HTML or other web client code are contextually encoded manually or use templates that automatically encode contextually to prevent reflected, saved, and DOM XSS attacks.
The program resists XPath query tampering, XML External Entity assaults, and XML injection attacks.
Content with a file path does not expose the application to RFI or LFI.
Security safeguards prevent OS Command Injection or the application is not vulnerable.
The program is LDAP Injection-proof or security rules prohibit it.
All SQL queries, HQL, OSQL, NOSQL, and stored procedures are secured from SQL injection by prepared statements or query parameterization.
For each allowed data type, the application uses one input validation control.
Server-side input validation techniques deny requests and log errors.
The runtime environment is buffer overflow-proof and security controls prevent them.
Encryption At Rest
All cryptographic modules fail securely, and mistakes are handled without oracle padding.
Check that all keys and passwords are produced or updated during installation
To prevent memory dumping, sensitive passwords and key material are erased with zeros when no longer needed.
Application cryptographic algorithms are FIPS 140-2 or equivalent-validated.
All cryptographic modules fail securely, and mistakes are handled without oracle padding.
Error Handling and Logging
Security logs are safeguarded against unwanted access and change.
To prevent log injection, all non-printable symbols and field separators are appropriately encoded in log entries.
Log fields from trusted and untrusted sources can be distinguished in log entries, and an audit log or similar enables for key transaction non-repudiation.
With proper log rotation, the logs are kept on a different partition than the program.
To ensure that logs have the right time, time sources should be synchronized.
Data Protection and verification
List application data classified by Software Company’s Information Classification Standard. Data flow diagrams should show this. According to the Software business Data Handling Matrix, enforcement must be explicit.
Ensure sensitive data is supplied to the server in the HTTP message body or headers (never URL parameters).
The risk tier and data handled by the program determine its anti-caching headers.
The server protects all cached or temporary copies of sensitive data from unauthorized access or purges/invalidates them after allowed access.
Check that the application minimizes request parameters such hidden fields, Ajax variables, cookies, and header data.
PII is not kept in client-side storage like HTML5 local storage, session storage, Indexed DB, normal cookies, or Flash cookies.
When no longer needed, sensitive memory data is erased with zeros to prevent memory dumping.
Communications Security
Validate that a path can be constructed from a trusted CA to each Transport Layer Security (TLS) server certificate and that each certificate is valid. Also ensure that certificate paths are constructed and validated for all client certificates using configured trust anchors and certificate revocation information.
Approved version of TLS and set of cipher suites are used for connections (including both external and backend connections) that pass RESTRICTED or CONFIDENTIAL data according to the Software company Information Classification Standard on public networks, and it does not fall back to insecure or unencrypted protocols. Ensure that the algorithm with the strongest alternative is the chosen one.
Ensure that a single standard TLS implementation is used by the application and its components, and that it is configured according to the Information Security Encryption Standard.
HTTP Security Configuration Verification
Only a predefined set of required HTTP request methods, such as GET and POST, are accepted by the application, while inactive methods (such as TRACE, PUT, and DELETE) are explicitly blocked.
Each HTTP response includes a content-type header that specifies a secure character set (such as UTF-8 or ISO 8859-1).
The application authenticates HTTP headers appended by a trusted proxy or SSO device, such as a bearer token.
Appropriate X-FRAME-OPTIONS Sites whose content should not be viewed in a third-party X-Frame employ headers.
HTTP headers and any other component of the HTTP response do not reveal version-specific information about system components.
Verify that all API responses contain the headers X-Content-Type-Options: nosniff and Content-Disposition: attachment; filename=”api.json” (or another filename that corresponds to the content type).
Content security policy version 2 (CSPv2) is in place to mitigate common DOM, XSS, JSON, and JavaScript injection flaws.
The preface X-XSS-Protection: 1; mode=block enables browser reflected XSS filters.
Files and Resources Verification
Avoid using Flash, Active-X, Silverlight, NACL, client-side Java, and any other client-side technologies that are not inherently supported by W3C browser standards.
Enforce Same-Origin Policy and/or implement Content Security Policy to protect against XSS, Clickjacking and other code injection attacks.
