A Session Cookie Does Not Prove the User Clicked

A session cookie says which account the browser is using. It does not say who chose the request. Imagine an AI dashboard where a signed-in owner can rotate an API key, change billing details, or delete a workspace. A hostile page can try to make that browser send one of those requests. The browser may attach the dashboard’s cookie. That is the opening for cross-site request forgery (CSRF), as the OWASP prevention guide explains.

The defense belongs at the server endpoint. A disabled button or a warning in the interface cannot establish that the request came from that interface. Build one policy for every route that changes state, then make each route enforce it before doing the work.

Map the actions that change state

List the dashboard’s writes: saving settings, starting paid jobs, inviting members, publishing content, changing credentials, and deleting data. Include browser forms, JavaScript requests, and old endpoints. The list is a design exercise, not a claim that every dashboard has these features.

Keep GET, HEAD, and OPTIONS free of state changes. A link can cause a GET, and SameSite=Lax still permits cookies on top-level navigations using safe methods. Moving a delete action from GET to POST is necessary, but the POST still needs a CSRF defense. OWASP calls for server validation on state-changing requests and warns against writes through GET. Read its route and cookie guidance.

Bind a token to the session

For a dashboard with server-side sessions, use the framework’s built-in CSRF protection when it fits. Otherwise, generate a secret, unpredictable token for each session. Store it with that session. Send it to the dashboard in an HTML or JSON response. Return it in a hidden form field or a custom header such as X-CSRF-Token. On every write, reject a missing token or one that does not match the current session. OWASP recommends this synchronizer token pattern for stateful applications. Its token guidance also notes that a token per request can cause trouble with the browser Back button.

Do not put this token in a URL or server log. For this pattern, do not use a cookie as the way to send the token back to the server. The browser sends cookies automatically, which is the behavior the defense must account for. If the dashboard cannot keep server-side token state, OWASP describes a signed double-submit cookie bound to the login session. A simple comparison between a cookie and a submitted value is vulnerable to cookie injection. The alternatives are described here.

Add browser signals around the token

Inspect Sec-Fetch-Site on writes. Reject cross-site requests. Allow same-origin requests that pass the token check. Treat same-site as a separate case when sibling subdomains are outside your control. If the header is absent, check Origin against the dashboard’s configured origin. Use Referer as the fallback when Origin is absent, and reject requests when neither supplies acceptable evidence on sensitive routes. OWASP recommends an origin fallback for clients without Fetch Metadata headers. Its policy examples distinguish same-origin, same-site, and cross-site; MDN defines those values.

Use a configured target origin, especially behind a proxy, and compare the full origin. A substring check can mistake an attacker-controlled host for yours. Keep intentional cross-origin endpoints on an explicit list with their own defenses. If a cookie-backed API uses a custom header as a CSRF defense, allow credentialed cross-origin requests only from origins you control. Otherwise, a permitted origin can send that header. OWASP covers both origin checks and the custom-header limit.

Treat cookies as a supporting layer

Set the session cookie with Secure, HttpOnly, and an explicit SameSite policy. Choose Lax if users need to follow outside links into the signed-in dashboard; Strict blocks the cookie on those cross-site visits too. A __Host- cookie also needs Secure, Path=/, and no Domain attribute, which keeps a sibling subdomain from setting it. MDN documents the prefix rules. OWASP explains the SameSite trade-off and its limits.

Do not count SameSite as the whole policy. It works at the site boundary, while a sibling host can still be same-site. It also leaves a state-changing GET exposed under Lax. For a sensitive action such as changing an account’s recovery settings, add a deliberate confirmation or re-authentication step alongside the request checks. OWASP recommends user interaction for security-critical operations. See its layered defenses.

Check the dashboard’s own requests

A malicious link can also steer dashboard JavaScript. If code reads a URL fragment and uses it to choose a request method or endpoint, that code may send the cookie and CSRF header itself. Keep write endpoints and methods fixed in code, or validate any input that selects them against a narrow allowlist. This is the client-side CSRF case in OWASP’s guide. The guide also warns that cross-site scripting can defeat CSRF defenses, so the dashboard needs its normal script-injection defenses as well.

What to do

1. Inventory every state-changing route, including login and older API paths. Remove writes from GET.
2. Enable the framework’s CSRF protection or bind a synchronizer token to each server-side session. Enforce it before every write.
3. Add Sec-Fetch-Site and full-origin checks. Define the missing-header path and review each cross-origin exception.
4. Set the session cookie’s security attributes. Keep credentialed cross-origin access to specific trusted origins.
5. Exercise a legitimate write, then try missing and wrong tokens, a cross-site form, a sibling-subdomain request, absent browser headers, and a crafted URL fragment. Confirm the rejected requests cause no state change.