Glossary

CSRF

CSRF exploits the trust an application places in a signed-in cookie-based session. Protection verifies that a request to make a change really originated in the legitimate application interface, not merely in the user’s browser.

Short definition

A cookie confirms the session, not the origin of the user intent.

In a CSRF attack, the attacker does not need to know the password or read the administration interface. It is enough for the victim to be signed in to the target application and visit a malicious website. That site can, for example, submit a form to an endpoint that changes an email address, cancels an order, or creates a new user. In some situations, the browser automatically attaches the cookie of the target application to the request.

For mutating requests, the target application therefore verifies additional proof of origin: most often a CSRF token passed in a form or header, or a consistent Origin or Referer according to the application design. A token is not a substitute for authentication and authorization. It adds the question of whether the request originated in the expected user interface.

Where it is used

Every cookie-based session with state-changing actions

CSRF protection primarily belongs in web UIs that use cookie-based sessions.

HTML forms in online-store administration and internal systems
changing a password, email, role, address, payment settings, or credentials
POST, PUT, PATCH, and DELETE endpoints called by a signed-in browser client
AJAX requests that carry a session cookie and change server-side data
login and logout when their flow and risk require protection against login CSRF

Practical example

Cancelling an order from the administration interface

A staff member opens the order detail, and the server creates a CSRF token for the cancellation action together with the form. On submission, the application checks the signed-in session and token, as well as the user permission to modify an order in the given organisation. Only then does it perform the business change in a transaction.

An attacker website can create an ordinary HTML form, but does not know the token bound to the staff session. If the token is invalid, nothing changes and the application returns a safe error response. The CSRF token is not placed in a URL or logs; it is not a credential for calling the API from any client.

<form method="post" action="/orders/4812/cancel">
  <input type="hidden" name="_token"
         value="{serverem-vygenerovaný-token-pro-akci-cancel-order}">
  <button type="submit">Zrušit objednávku</button>
</form>

How it works

From displaying a form to making a change safely

Protection adds to the automatically sent session a value that another origin normally cannot obtain.

The user opens the page The application verifies the session and creates or loads a token intended for the user, session, or specific planned action.
The form or JavaScript carries the token The token is placed in a hidden form field or an expected request header, not in the URL.
The browser sends the request A session cookie may be attached to the request. The token provides additional proof that the request was prepared by a trusted client.
The server compares the value Middleware or a security layer verifies the token before changing data; failure leads to rejection without a side effect.
The application authorizes the action After the CSRF check, it still verifies the role, tenant, resource ownership, and business rule. The token grants no permission.

Key concepts

A token, cookie, and request origin play different roles.

Reliable protection is not about choosing a header name; it designs a flow for a particular type of client and session.

Synchronizer token

The server stores or derives a token bound to the session and passes a second copy to the form. The values must match when a mutation is requested. The token is generated with cryptographic randomness and checked on the server.

Double-submit cookie

Another pattern compares a value in a cookie with one in the request. Preventing an attacker from setting both values arbitrarily requires carefully designed binding, secure cookie settings, and a correctly chosen trust context.

SameSite cookie

SameSite restricts when a browser attaches a cookie in a cross-site context. It is a useful defensive layer, but depends on the mode, navigation, and legitimate login requirements; it is not the sole CSRF defence.

Origin and Referer

Checking the expected Origin or a safe Referer can reveal a mutation from another site. Depending on the architecture, this serves as a supplement or alternative, but must account for proxies and documented browser behaviour.

Safe methods

GET, HEAD, and other read-only operations must not change business state. A CSRF token does not justify using GET to cancel an order or change a password.

Benefits and limitations

Protection works only for a correctly defined session flow.

Benefits

prevents another website from making a mutation merely because the session cookie is attached
gives forms and AJAX mutations a consistent server-side contract
adds multiple independent layers when combined with SameSite and Origin checks
failure can be tested as a rejected request without a side effect

Risks and mistakes

relying on CORS or a hidden button instead of verifying the token on the server
placing the token in URLs, logs, or analytics tools
allowing GET to change data and claiming CSRF applies only to POST forms
assuming a CSRF token protects the application from XSS running in the same origin

When it is required

A cookie-based website needs protection for every important mutation.

CSRF protection is a standard part of a stateful web application: administration interfaces, customer accounts, order flows, and internal systems commonly use cookie-based sessions and forms. A framework can simplify token generation and validation, but the team must identify state-changing endpoints, define safe methods, and ensure every alternative input has the same protection.

A purely machine-to-machine API using an access token passed exclusively in an explicit header does not have the same cookie CSRF vector. The real client behaviour still needs to be examined: a token in a cookie, browser credentials, or a mix of sessions and APIs can reintroduce the risk. The security rule follows browser behaviour, not the endpoint name.

What to consider

Protect mutations consistently across the UI and API.

The best protection is uneventful and ubiquitous: it does not rely on every controller author remembering to validate a token.

enable the framework CSRF middleware for stateful browser paths and avoid exceptions without a reason
keep GET, HEAD, and other safe methods free of business changes
do not transmit a CSRF token in a URL or write it to application and analytics logs
set Secure, HttpOnly, and an appropriate SameSite mode on the session cookie to match the actual login flow
test a valid token, missing token, token from another session, and a mutation from another origin

Common questions

When a token protects you and when it does not

Do I need a CSRF token when using a cookie-based session?

Usually yes for mutating browser requests. The browser may attach a cookie even to a request initiated by another website. A token or another suitable server-side check verifies the origin of the intent.

Does CORS replace CSRF protection?

No. CORS mainly restricts whether third-party JavaScript can read the response. In some cases, a third-party form can send the request even without being able to read the response.

Is a SameSite cookie enough?

SameSite helps significantly, but it is not a universal replacement for a token. It depends on the cookie mode, navigation, compatibility, and legitimate cross-site login flows.

Does a CSRF token protect against XSS?

No. A script running within the same origin can use the token from the page. XSS is prevented through safe output, restrictions on dangerous HTML, and additional layers such as CSP.

How I approach backends in practice

I combine security checks with permissions and the real data flow.

For internal systems and e-commerce, I address form protection, API boundaries, session handling, roles, and safe data changes.

How I use PHP in practice Discuss your project without obligation