Got Cookies? Exploring Cookie Based Authentication Vulnerabilities in the Wild

Cookie Based Authentication Vulnerabilities Mind Map

Attack Scenarios

Now, we will take a look at some of the interesting attack scenarios from the above mind map. To give you the tools to better understand your large attack surface when you stumble upon cookies.

Attack — 1: Insecure Direct Object Reference

Let’s assume an application is using cookie-based authentication and supplying a userid parameter in the cookies. However, there is no validation of this userid with other session identifiers due to which an attacker can simply change the userid to the victim user’s id and gain access to its account.

GET /userinfo
Cookies: sessionid=somerandomsessionID;userid=1234;someothercookies=values
GET /userinfo
Cookies: sessionid=somerandomsessionID;userid=1235;someothercookies=values

Attack — 2: Privilege Escalation

In this scenario, if cookies are used to define the role (or any other similar key-value pairs that defines some privileges/access rights) and there is no validation, an attacker can abuse this behavior to perform a Privilege Escalation.

1. Login as a victim user and capture the request with Burp Suite.2. In Cookies section there was a ROLE parameter which has a two-digit value 00.3. Create an admin account and observe that now ROLE value in cookies is 11.4. Upon further inspection and mapping User Role & Permission Matrix. I observed that the application uses binary bits for role definition.00 : User
11 : Admin
5. Now, by changing the ROLE parameter in normal user account to 11, It was possible to perform a successful privilege escalation in Admin User Role.

Attack — 3: File Inclusion

It may sound weird that an attacker can potentially utilize cookies to perform a file inclusion attack, but security issues can arise at any point depending on how an application is implementing various features.

Cookie: banner=welcome.php; someothercookies=value; 
Cookie: banner=../../../../../../../../etc/passwd; someothercookies=value;

Attack — 4: Cross-Site Scripting

Many applications utilize cookies to display the username or some sort of message within the application user interface. An attacker can tamper with such cookies and inject a malicious JavaScript payload resulting in a Self-XSS.

Original Cookies
Cookie: name=harsh;somecookies=value
Modified Cookies
Cookie: name=<script>alert(document.domain)</script>; somecookies=value

Attack — 5: Guessable/Weak Cookie

  1. Check if the cookies are generated randomly by issuing multiple cookies and analyzing them.
  2. Check if some weak or known cryptography is used. Let’s assume the cookies are using Base64 Encoding and can be decoded/forged easily.

Attack — 6: Sensitive Data Exposure

Sometimes cookies are used to store user’s personal information, especially in Health Care related applications. Always check for the following:

a. Check if any PII or Other Sensitive Information Stored in Cookies by simply using DevTools/Burp Suite/Cookie Editor
b. This information usually includes: Email, Date of Birth, Mobile, Address, SSN, Etc.

Attack — 7: Direct Request/Authorization Bypass

Let’s assume that the application has the following endpoint which allows an authenticated user to view some protected sensitive information.

GET /protected-resource
Cookies: sessionid=somesessionID; someotherkey=value
GET /protected-resource

Attack — 8: Insecure Deserialization

If the cookies are using any serialized object, it is possible to perform object injection or serialization-based attacks. This allows an attacker to perform privilege escalation, authentication bypass, and other attacks based on how serialized objects are used.

Attack — 9: Mass Assignment/Parameter Pollution

If an application accepts the use of a duplicate parameter (the same parameter used multiple times) or multiple values within the same parameter, it may be vulnerable to Parameter Pollution or Mass Assignment Attacks.

1. Assume that the cookies utilize a parameter called "user_id=" to retrieve some data. However, the application is not vulnerable to IDOR and changing "user_id=" to victim value, doesn't help out.2. An Attacker tries to add an additional "user_id=" parameter value to the cookie with victim's user ID. Like: "user_id=attacker&user_id=victim" 3. As a result, an attacker is able to retrieve the data of Victim User as the application's parameter processing preference is given to the later parameter and the checks are bypassed. 

Attack — 10: Missing Cookie Security Attributes

This is a simple security misconfiguration and is easy to check. As soon as you log in to the application, use any cookie editor or Browser Developer Tools (preferred) to see if the cookies are missing the following attribute (flags not set):

  • HTTPOnly: Protects cookies from being stolen using Scripting Attacks such as XSS.
  • Secure: Protects cookies from being stolen over Insecure Communication channels and attacks such as Man-in-the-Middle attacks.


  1. Implement all the required cookie security attributes such as HTTPOnly & Secure.
  2. Ensure that plain cookies are not used to define the privileges. For example, sending role parameters to define privilege should not be implemented.
  3. Ensure that no sensitive data is directly used in cookies. If due to any business requirements it is required to used this data, make sure it’s strongly encrypted and can’t be decrypted.
  4. Always perform validations on the protected endpoints and ensure that they are not accessible without authentication.
  5. Prefer token-based authentication over cookie-based authentication or implement an additional Authorization header to make sure such attack attempts are reduced to a greater extent.
  6. Never allow reading server-side components such as files using cookies & ensure that the proper validation checks are in place to mitigate such attacks.


  1. Always check for weak cryptography in the cookies or check if any known library is used to generate the cookies. This may often allow you to perform an account takeover resulting in critical severity issues.
  2. Always map an application to understand what values are dynamically changed using session identifiers/variables and try to abuse them.
  3. Always look for Server-Side issues in the Cookies as well. In many cases, you may find interesting security vulnerabilities.
  4. Check if the cookies are properly validated for the protected resources, failing to do so may result in authorization bypass.
  5. Always, always dig deep, and when you encounter cookies next time, you know what you need to do next ;)



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Harsh Bothra

Harsh Bothra

Security Engineer | Bugcrowd Top 150 & MVP| Synack Red Teamer | Cobalt Core Pentester | Bug Hunter | Author | Speaker | Learner | Poet | Twitter — @harshbothra_