CON.10 Development of Web Applications

Developers MUST ensure that users securely and appropriately authenticate themselves to a web application before they can access protected functions or content. An appropriate authentication method MUST be selected. The selection process MUST be documented.

A central authentication component MUST be used. The central authentication component SHOULD be used with established standard components (e.g. from frameworks or program libraries). If a web application stores authentication data on a client, the user MUST be explicitly informed about the risks of this function and consent to it (“opt-in”).

The web application MUST offer the option to set limits for failed login attempts. The web application MUST inform users immediately if their password has been reset.

An authorisation component MUST be used by Developers to ensure that users can only perform actions for which they are authorised. Every attempt to access protected content and functions MUST be checked before being allowed.

The authorisation component MUST consider all the resources and content administered by a web application. If the corresponding access control system is defective, access MUST be denied. Access control MUST also be in place for URL calls and object references.

Developers MUST ensure that session IDs are protected appropriately. Session IDs MUST be generated randomly and with sufficient entropy. If the web application framework in use can generate secure session IDs, the Developers MUST use this feature. The security-relevant configuration options of the framework MUST be considered. If session IDs are transmitted and stored by the clients, they MUST be transmitted with sufficient protection.

A web application MUST provide users with the option to expressly terminate an active session. After a user has logged in, any existing session ID MUST be replaced by a new one. Sessions MUST have a maximum validity period (timeout). Inactive sessions MUST automatically expire after a specified period of time. After a session has become invalid, all the session data MUST be rendered invalid and deleted.

Developers MUST ensure that a web application only integrates the intended content for delivery to the user.

The destinations of the redirection function of a web application MUST be restricted sufficiently so that users are only redirected to trustworthy websites. If a user is leaving a trustworthy domain, the web application MUST inform them of this.

Developers MUST ensure that a user can only save files under the specified path. Developers MUST ensure that a user cannot influence the storage location for uploads. Developers MUST integrate functions into their web applications that allow operators of the applications to configure uploads.

Developers MUST implement security mechanisms that protect their web applications from automated access. When implementing the security mechanisms, Developers MUST consider how they affect the options available to authorised users.

Developers MUST ensure that confidential data is transferred from clients to servers using only the HTTP post method.

Developers MUST use directives in web applications to ensure that no sensitive data is cached on the client side. Developers MUST ensure that no confidential form data is displayed in plain text in forms. A web application SHOULD prevent confidential data from being stored unexpectedly by the web browser. All web application access data MUST be protected against unauthorised access on the server side with the help of cryptographic algorithms (salted hash). The files containing the source code of a web application MUST be protected against unauthorised retrieval.

Developers MUST treat all data passed to a web application as potentially dangerous and filter it appropriately. All input data, as well as data streams and secondary data (such as session IDs), MUST be validated on the server side.

The automatic handling of erroneous input SHOULD be minimised (through sanitising) to the greatest extent possible. If it is unavoidable, sanitising MUST be implemented securely.

Output data MUST be encoded so that malicious code is not interpreted or executed on the target system.

If data is passed to a database management system (DBMS), Developers MUST use stored procedures or prepared SQL statements. If data is passed to a DBMS and neither stored procedures nor prepared SQL statements are supported by the operational environment, SQL queries MUST be secured separately.

Developers MUST ensure that webpages, responses, and error messages from web applications do not contain information that would provide an attacker with insights into how to bypass corresponding security mechanisms.

Developers SHOULD document the software architecture of their web applications along with all their components and dependencies. The documentation SHOULD be updated and adapted during the development process. The documentation SHOULD be designed so that it can be used in the development phase and the decisions taken will be comprehensible. The documentation SHOULD identify all the components necessary for operation that are not part of the respective web application. The documentation SHOULD also describe which components implement which security mechanisms, how the web application is to be integrated into an existing infrastructure, and which cryptographic functions and procedures are used.

If important settings are to be changed with an application, the Developers SHOULD ensure that the changes are verified again by entering a password. If this is not possible, the web application SHOULD ensure that users authenticate themselves by other appropriate means. Users SHOULD be informed of changes via communication channels outside the web application.

If errors occur during the runtime of a web application, the Developers SHOULD ensure that the application handles them in a way that enables it to remain in a consistent state.

The web application SHOULD log error messages. If an initiated action causes an error, the web application SHOULD cancel that action. If an error occurs, the web application SHOULD deny access to the resource or function being requested.

Previously reserved resources SHOULD be released within the framework of error handling. Errors SHOULD be handled by the web application itself whenever possible.

To protect against clickjacking, cross-site scripting, and other attacks, Developers SHOULD set appropriate HTTP response headers. The following HTTP headers SHOULD be used at minimum: Content-Security-Policy, Strict-Transport-Security, Content-Type, X-Content-Type-Options, and Cache-Control. The HTTP headers used SHOULD be adapted to the web application at hand. The HTTP headers used SHOULD be as restrictive as possible.

Cookies SHOULD always be set with the attributes secure, SameSite, and httponly.

Developers SHOULD equip web applications with the security mechanisms required to distinguish between users' intended page requests and unintentionally forwarded third-party commands. At minimum, whether a secret token is required in addition to the session ID for access to protected resources and functions SHOULD be checked.

Developers SHOULD implement multi-factor authentication.

As protection against denial-of-service (DoS) attacks, resource-intensive operations SHOULD be avoided. Where resource-intensive operations are necessary, a particular effort SHOULD be made to secure them. For web applications, potential overflows of log data SHOULD be monitored and prevented.

Developers SHOULD ensure that a web application's confidential data is protected by secure cryptographic algorithms.