Cookie Poisoning

Improper neutralization of external input stored into a cookie ('Cookie Poisoning').

If an attacker inserts a malicious payload into a browser cookie, the application might mistakenly accept it as legitimate.

This compromised cookie could then bypass security measures, alter user settings, or execute unexpected actions under the logged-in user’s identity.

Furthermore, since cookies are usually specified in the 'Set-Cookie' HTTP header within the response message, an attacker could also initiate a header manipulation attack by including CR/LF characters.

Depending on how the cookie is used, the attacker could compromise authentication, session management, or leak sensitive information.

Ensure all user inputs are validated and sanitized before inclusion in cookies.

A strict whitelisting pattern could be used to prevent unintended modification of the cookie properties. A blacklist pattern that blocks dangerous characters(;, ,, =, CR/LR, etc.) in the user-controlled input to use in the cookie value is also possible, but a whitelisting pattern is recommended.

It is common to base64-encode the cookie value before storing it in the cookie: the given value cannot alter the cookie properties (Max-Age / Expires, Domain, Path, Secure, HttpOnly, SameSite). This approach also avoids the cookie poisoning issue, when any value is allowed for the cookie value.

An alternative to cookies is server-side session storage, if possible. This way you eliminate cookie poisoning risk completely.

For session cookies, never make them dependent on external input. The session identifiers must be unique and randomly generated so that they are not predictable, and unusable after the session is closed. If possible, do not reinvent the wheel and implement your own session handling, as mature session libraries and frameworks exist.

Another important design principle is to use each cookie for only one task. It can be tempting to use multi-purpose cookies, but this creates security risks. Never mix session identifiers, anti-CSRF tokens, password reset tokens or 'remember-me' tokens in the same cookie.

Cookie properties should have appropriate values, such as HttpOnly and Secure flags, in addition to avoiding cookie poisoning. The unsafe_cookie detector can be used to detect misconfigurations in cookie properties.

The detector has the following configurable parameters:

Unless you need to change the default behavior, you typically do not need to configure this detector.