Cross-Site Request Forgery (CSRF) is one of those vulnerabilities that often appears simple in theory but can have serious consequences when discovered in real applications. During testing, I encountered a CSRF issue in a profile update functionality that allowed user information to be modified without verifying the legitimacy of the request. After analyzing the issue, I decided to recreate the entire scenario locally as a security lab to better understand both the attack path and the architectural defenses required to prevent it.

TL;DR

• Found a CSRF vulnerability on a profile update endpoint • The server trusted session cookies without validating request origin • This allowed attackers to trigger actions on behalf of a logged-in user • I recreated the vulnerability in a local lab to demonstrate both exploitation and proper mitigation.

Full video walkthrough: https://www.youtube.com/watch?v=uynNuhTe39U Lab available here: https://github.com/AkashA1511/Vulnerable_Apps/tree/main/CSRF

What is CSRF?

Cross-Site Request Forgery occurs when an application performs sensitive actions solely based on the presence of a user's authenticated session cookie. Browsers automatically attach cookies to requests made to a domain. Because of this behavior, an attacker can trick a logged-in user into sending a malicious request to the application without their knowledge. If the server does not verify where the request originated from, it will process the action as if it were legitimate. This means attackers can potentially perform actions such as:

  • modifying account details
  • changing email addresses
  • initiating transactions
  • deleting user data all without the victim realizing it.

Observations During Testing

While testing the profile update functionality, a few things immediately stood out from a security perspective. The application relied entirely on a session cookie to authenticate requests, but there were no mechanisms in place to verify whether a request originated from the legitimate application interface. Specifically, the endpoint lacked several protections that are commonly used to defend against CSRF attacks. There was: • no CSRF token in the form submission • no validation of request origin • no referer validation • no SameSite restriction on session cookies Because of this, any request containing a valid session cookie would be accepted by the server.

Confirming the Vulnerability

To confirm whether the endpoint was actually vulnerable, I generated a CSRF proof-of-concept request and tested it while authenticated in the application. The malicious request successfully triggered the profile update action. From the server's perspective, the request looked completely legitimate because it included the victim's session cookie. This confirmed that the application did not distinguish between requests coming from the real application and requests originating from external websites.

Why This Matters

At first glance, modifying profile information might appear like a minor issue. However, vulnerabilities like this can often be chained with other application functionality to create much more serious outcomes. For example, if an attacker were able to change a victim's email address to one they controlled, they could then trigger a password reset flow. The reset link would be sent to the attacker's email, potentially allowing them to take over the account. This demonstrates how even seemingly small issues can escalate when combined with other features of the application.

Recreating the Vulnerability as a Security Lab

To better understand the vulnerability and demonstrate how it should be fixed, I recreated the scenario as a local security lab. The lab environment includes: • a vulnerable application demonstrating the CSRF issue • an attacker page that performs the exploit • a patched version showing proper defensive controls Instead of focusing only on exploitation, the goal of the lab is to demonstrate how CSRF protection should be implemented from an architectural standpoint.

Security Architecture Perspective

Modern applications should never rely on a single control to prevent CSRF attacks. A secure design typically combines multiple defensive layers. These commonly include: SameSite cookie policies Restrict cookies from being sent with cross-origin requests. CSRF tokens Ensure that each request contains a secret value generated by the application. Origin and Referer validation Verify that the request originates from the expected domain. When these protections are implemented together, CSRF attacks become extremely difficult to exploit.

CSRF Security Lab

To help security learners and developers understand the vulnerability and its mitigation, I published the full lab environment on GitHub. The repository demonstrates: • how the vulnerable workflow behaves • how attackers can exploit the issue • how the architecture can be secured Explore the lab here: https://github.com/AkashA1511/Vulnerable_Apps/tree/main/CSRF

Quick CSRF Testing Checklist

When testing applications for CSRF vulnerabilities, these are some of the things I usually look for: • Does the application rely only on session cookies for authentication? • Is the session cookie missing the SameSite attribute? • Do sensitive forms lack CSRF tokens? • Does the server validate Origin or Referer headers? • Are critical actions like email change or password reset protected? If multiple protections are missing, the endpoint may be vulnerable.

Final Thoughts

CSRF vulnerabilities are often overlooked during development because they don't cause obvious errors — the application simply processes the request normally. However, as seen in this scenario, small security gaps in request validation can potentially lead to larger issues when combined with other application features. Building small reproducible labs like this is one of the best ways to deeply understand both how vulnerabilities work and how they should be mitigated.

If you're interested in offensive security and vulnerability research, you can explore more security labs and projects here:

GitHub: https://github.com/AkashA1511