Display Generic Error Messages

Error messages should not reveal details about the internal state of the application. For example, file system path and stack information should not be exposed to the user through error messages.

CWE-209

No Unhandled Exceptions

Given the languages and frameworks in use for web application development, never allow an unhandled exception to occur. Error handlers should be configured to handle unexpected errors and gracefully return controlled output to the user.

CWE-391

Suppress Framework Generated Errors

Your development framework or platform may generate default error messages. These should be suppressed or replaced with customized error messages as framework generated messages may reveal sensitive information to the user.

CWE-209

Log All Authentication Activities

Any authentication activities, whether successful or not, should be logged.

CWE-778

Log All Privilege Changes

Any activities or occasions where the user's privilege level changes should be logged.

CWE-778

Log Administrative Activities

Any administrative activities on the application or any of its components should be logged.

CWE-778

Log Access to Sensitive Data

Any access to sensitive data should be logged. This is particularly important for corporations that have to meet regulatory requirements like HIPAA, PCI, or SOX.

CWE-778

Do Not Log Inappropriate Data

While logging errors and auditing access is important, sensitive data should never be logged in an unencrypted form. For example, under HIPAA and PCI, it would be a violation to log sensitive data into the log itself unless the log is encrypted on the disk. Additionally, it can create a serious exposure point should the web application itself become compromised.

CWE-532

Logs should be stored and maintained appropriately to avoid information loss or tampering by intruder. Log retention should also follow the retention policy set forth by the organization to meet regulatory requirements and provide enough information for forensic and incident response activities.

CWE-533

Use HTTPS Everywhere

Ideally, HTTPS should be used for your entire application. If you have
to limit where it's used, then HTTPS must be applied to any
authentication pages as well as to all pages after the user is
authenticated. If sensitive information (e.g. personal information) can
be submitted before authentication, those
features must also be sent over.

Example: Firesheep

CWE-311
CWE-319
CWE-523

Disable HTTP Access for All Protected Resources

For all pages requiring protection by HTTPS, the same URL should not be accessible via the insecure HTTP channel.

CWE-319

Use the Strict-Transport-Security Header

The Strict-Transport-Security header ensures that the browser does not talk to the server over HTTP. This helps reduce the risk of HTTP downgrade attacks as implemented by the sslsniff tool.

Store User Passwords Using a Strong, Iterative, Salted Hash

User passwords must be stored using secure hashing techniques with
strong algorithms like PBKDF2, bcrypt, or SHA-512. Simply hashing the
password a single time does not sufficiently protect the password. Use
adaptive hashing (a work factor), combined with a randomly generated
salt for each user to make the hash strong.

Example: LinkedIn password leak

CWE-257

Securely Exchange Encryption Keys

If encryption keys are exchanged or pre-set in your application then any key establishment or exchange must be performed over a secure channel

Set Up Secure Key Management Processes

When keys are stored in your system they must be properly secured and
only accessible to the appropriate staff on a need to know basis.

Example: AWS Key Management Service (KMS), Azure Key Vault, AWS CloudHSM

CWE-320

Weak TLS Configuration on Servers

Weak ciphers must be disabled on all servers. For example, SSL v2, SSL
v3, and TLS protocols prior to 1.2 have known weaknesses and are not
considered secure. Additionally, disable the NULL, RC4, DES, and MD5
cipher suites. Ensure all key lengths are greater than 128 bits, use
secure renegotiation, and disable compression.

Example: Qualys SSL Labs

Use Valid HTTPS Certificates from a Reputable CA

HTTPS certificates should be signed by a reputable certificate
authority. The name on the certificate should match the FQDN of the
website. The certificate itself should be valid and not expired.

Example: Let's Encrypt (https://letsencrypt.org)

Disable Data Caching Using Cache Control Headers and Autocomplete

Browser data caching should be disabled using the cache control HTTP headers or meta tags within the HTML page. Additionally, sensitive input fields, such as the login form, should have the autocomplete=off setting in the HTML form to instruct the browser not to cache the credentials.

CWE-524

Limit the Use and Storage of Sensitive Data

Conduct an evaluation to ensure that sensitive data is not being unnecessarily transported or stored. Where possible, use tokenization to reduce data exposure risks.

Automate Application Deployment

Automating the deployment of your application, using Continuous Integration and Continuous Deployment, helps to ensure that changes are made in a consistent, repeatable manner in all environments.

Establish a Rigorous Change Management Process

A rigorous change management process must be maintained during change
management operations. For example, new releases should only be deployed
after process

Example: RBS production outage (http://www.computing.co.uk/ctg/analysis/2186972/rbs-wrong-rbs-manager)

CWE-439

Define Security Requirements

Engage the business owner to define security requirements for the application. This includes items that range from the whitelist validation rules all the way to nonfunctional requirements like the performance of the login function. Defining these requirements up front ensures that security is baked into the system.

Conduct a Design Review

Integrating security into the design phase saves money and time. Conduct a risk review with security professionals and threat model the application to identify key risks. The helps you integrate appropriate countermeasures into the design and architecture of the application.

CWE-701
CWE-656

Perform Code Reviews

Security focused code reviews can be one of the most effective ways to find security bugs. Regularly review your code looking for common issues like SQL Injection and Cross-Site Scripting.

CWE-702

Perform Security Testing

Conduct security testing both during and after development to ensure the application meets security standards. Testing should also be conducted after major releases to ensure vulnerabilities did not get introduced during the update process.

Harden the Infrastructure

All components of infrastructure that support the application should be configured according to security best practices and hardening guidelines. In a typical web application this can include routers, firewalls, network switches, operating systems, web servers, application servers, databases, and application frameworks.

CWE-15
CWE-656

Define an Incident Handling Plan

An incident handling plan should be drafted and tested on a regular basis. The contact list of people to involve in a security incident related to the application should be well defined and kept up to date.

Educate the Team on Security

Training helps define a common language that the team can use to improve the security of the application. Education should not be confined solely to software developers, testers, and architects. Anyone associated with the development process, such as business analysts and project managers, should all have periodic software security awareness training.

Don't Hardcode Credentials

Never allow credentials to be stored directly within the application
code. While it can be convenient to test application code with hardcoded
credentials during development this significantly increases risk and
should be avoided.

Example: Hard coded passwords in networking devices https://www.us-cert.gov/control_systems/pdf/ICSA-12-243-01.pdf

CWE-798

Develop a Strong Password Reset System

Password reset systems are often the weakest link in an application.
These systems are often based on the user answering personal questions
to establish their identity and in turn reset the password. The system
needs to be based on questions that are both hard to guess and brute
force. Additionally, any password reset option must not reveal whether
or not an account is valid, preventing username harvesting.

Example: Sara Palin password hack (http://en.wikipedia.org/wiki/Sarah_Palin_email_hack)

CWE-640

Implement a Strong Password Policy and Move Towards Passwordless Authentication

For password based authentication, password policy should be created and
implemented so that passwords meet specific strength criteria. If the
user base and application can support it, leverage the various forms of
passwordless authentication such as FIDO2 based authentication or mobile
application push based authenticators.

Example: http://www.pcworld.com/article/128823/study_weak_passwords_really_do_help_hackers.html

CWE-521

Implement Account Lockout against Brute Force Attacks

Account lockout needs to be implemented to guard against brute forcing attacks against both the authentication and password reset functionality. After several tries on a specific user account, the account should be locked for a period of time or until manually unlocked. Additionally, it is best to continue the same failure message indicating that the credentials are incorrect or the account is locked to prevent an attacker from harvesting usernames.

CWE-307

Don't Disclose Too Much Information in Error Messages

Messages for authentication errors must be clear and, at the same time, be written so that sensitive information about the system is not disclosed. For example, error messages which reveal that the userid is valid but that the corresponding password is incorrect confirms to an attacker that the account does exist on the system.

Store Database Credentials and API keys Securely

Modern web applications usually consist of multiple layers. The business logic tier (processing of information) often connects to the data tier (database). Connecting to the database, of course, requires authentication. The authentication credentials in the business logic tier must be stored in a centralized location that is locked down. The same applies to accessing APIs providing services to support your application. Scattering credentials throughout the source code is not acceptable. Some development frameworks provide a centralized secure location for storing credentials to the backend database. Secret management solutions that are cloud based or on-premise can be used to allow the application to acquire the credential at application launch or when needed, therefore securing the credentials and avoid storing them statically on disk within a server or a container image.

CWE-257

Applications and Middleware Should Run with Minimal Privileges

If an application becomes compromised it is important that the application itself and any middleware services be configured to run with minimal privileges. For instance, while the application layer or business layer needs the ability to read and write data to the underlying database, administrative credentials that grant access to other databases or tables should not be provided.

CWE-250

Ensure That Session Identifiers Are Sufficiently Random

Session tokens must be generated by secure random functions and must be of a sufficient length so as to withstand analysis and prediction.

CWE-6

Regenerate Session Tokens

Session tokens should be regenerated when the user authenticates to the application and when the user privilege level changes. Additionally, should the encryption status change, the session token should always be regenerated.

CWE-384

Implement an Idle Session Timeout

When a user is not active, the application should automatically log the user out. Be aware that Ajax applications may make recurring calls to the application effectively resetting the timeout counter automatically.

CWE-613

Implement an Absolute Session Timeout

Users should be logged out after an extensive amount of time (e.g. 4-8 hours) has passed since they logged in. This helps mitigate the risk of an attacker using a hijacked session.

CWE-613

Destroy Sessions at Any Sign of Tampering

Unless the application requires multiple simultaneous sessions for a single user, implement features to detect session cloning attempts. Should any sign of session cloning be detected, the session should be destroyed, forcing the real user to re-authenticate.

Invalidate the Session after Logout

When the user logs out of the application the session and corresponding data on the server must be destroyed. This ensures that the session can not be accidentally revived.

CWE-613

Place a Logout Button on Every Page

The logout button or logout link should be easily accessible to the user on every page after they have authenticated.

Use Secure Cookie Attributes (HttpOnly, Secure and SameSite Flags)

The session cookie should be set with both the HttpOnly and the Secure flags. This ensures that the session id will not be accessible to client-side scripts and it will only be transmitted over HTTPS, respectively. In addition, the SameSite attribute should be set to with either lax or straight mode to reduce the risk of Cross Site Request Forgery.

CWE-79
CWE-614
CWE-1004

Set the Cookie Domain and Path Correctly

The cookie domain and path scope should be set to the most restrictive settings for your application. Any wildcard domain scoped cookie must have a good justification for its existence.

Set the Cookie Expiration Time

The session cookie should have a reasonable expiration time. Non-expiring session cookies should be avoided.

Conduct Contextual Output Encoding

All output functions must contextually encode data before sending
it to the user. Depending on where the output will end up in the HTML
page, the output must be encoded differently. For example, data placed
in the URL context must be encoded differently than data placed in
JavaScript context within the HTML page.

Example: Resource: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

CWE-79

Prefer Allowlists over Blocklists

For each user input field, there should be validation on the input content. Allowlisting input is the preferred approach. Only accept data that meets a certain criteria. For input that needs more flexibility, blocklisting can also be applied where known bad input patterns or characters are blocked.

CWE-159
CWE-144

Use Parameterized SQL Queries

SQL queries should be crafted with user content passed into a bind
variable. Queries written this way are safe against SQL injection
attacks. SQL queries should not be created dynamically using string
concatenation. Similarly, the SQL query string used in a bound or
parameterized query should never be dynamically built from user input.

Example: Sony SQL injection Hack (http://www.infosecurity-magazine.com/view/27930/lulzsec-sony-pictures-hackers-were-school-chums)

CWE-89
CWE-564

Use Tokens to Prevent Forged Requests

In order to prevent Cross-Site Request Forgery attacks, you must embed a random value that is not known to third parties into the HTML form. This CSRF protection token must be unique to each request. This prevents a forged CSRF request from being submitted because the attacker does not know the value of the token.

CWE-352

Set the Encoding for Your Application

For every page in your application set the encoding using HTTP headers or meta tags within HTML. This ensures that the encoding of the page is always defined and that browser will not have to determine the encoding on its own. Setting a consistent encoding, like UTF-8, for your application reduces the overall risk of issues like Cross-Site Scripting.

CWE-172

Validate Uploaded Files

When accepting file uploads from the user make sure to validate the size of the file, the file type, and the file contents as well as ensuring that it is not possible to override the destination path for the file.

CWE-434
CWE-616
CWE-22

Use the Nosniff Header for Uploaded Content

When hosting user uploaded content which can be viewed by other users, use the X-Content-Type-Options: nosniff header so that browsers do not try to guess the data type. Sometimes the browser can be tricked into displaying the data type incorrectly (e.g. showing a GIF file as HTML). Always let the server or application determine the data type.

CWE-430

Validate the Source of Input

The source of the input must be validated. For example, if input is expected from a POST request do not accept the input variable from a GET request.

CWE-20
CWE-346

Use the X-Frame-Options Header

Use the X-Frame-Options header to prevent content from being loaded by a
foreign site in a frame. This mitigates Clickjacking
attacks. For older browsers that do not support this header add
framebusting Javascript code to mitigate Clickjacking (although this
method is not foolproof and can be circumvented).

Example: Flash camera and mic hack (http://jeremiahgrossman.blogspot.com/2008/10/clickjacking-web-pages-can-see-and-hear.html)

CAPEC-103
CWE-693

Use Secure HTTP Response Headers

The Content Security Policy (CSP), X-XSS-Protection,
X-Content-Type-Options headers help defend against Cross-Site Scripting
(XSS) attack. In specific, CSP should be customized for the application
to lock down the source and location of content plus adding logging to
provide some attack detection capability on the front end.

Example: OWASP Secure Headers Project

CWE-79
CWE-692

Deserialize Untrusted Data with Proper Controls

When handling serialized data from untrusted source (or passing through untrusted paths), proper controls have to be in place to prevent attacker from abusing the automatic data structure rebuilding capability within the programming language. Each programming platform has its own mitigation strategy which range from using alternative data interchange format such as JSON to restricting the types of objects that can be deserialized. Refer to OWASP Deserialization Cheat Sheet for some great defense information.

CWE-502

Apply Access Controls Checks Consistently

Always apply the principle of complete mediation, forcing all requests through a common security "gate keeper." This ensures that access control checks are triggered whether or not the user is authenticated.

CWE-284

Apply the Principle of Least Privilege

Make use of a Mandatory Access Control system. All access decisions will be based on the principle of least privilege. If not explicitly allowed then access should be denied. Additionally, after an account is created, rights must be specifically added to that account to grant access to resources.

CWE-272
CWE-250

Don't Use Direct Object References for Access Control Checks

Do not allow direct references to files or parameters that can be manipulated to grant excessive access. Access control decisions must be based on the authenticated user identity and trusted server side information.

CWE-284

Don't Use Unvalidated Forwards or Redirects

An unvalidated forward can allow an attacker to access private content without authentication. Unvalidated redirects allow an attacker to lure victims into visiting malicious sites. Prevent these from occurring by conducting the appropriate access controls checks before sending the user to the given location.

CWE-601