How to Protect Forms Against CSRF is an important topic for anyone developing secure websites and web applications. Cross-Site Request Forgery, commonly called CSRF, is a web security vulnerability where an attacker tricks a user’s browser into sending an unwanted request to a website where the user is already authenticated.

The important thing to understand is that the attack does not necessarily require the attacker to steal the user’s password.

Modern browsers automatically attach relevant cookies to requests. If a victim is logged into a website and visits a malicious page, that page may attempt to cause the victim’s browser to send a request to the trusted website. Without appropriate CSRF protection, the target application may incorrectly treat the request as legitimate. (OWASP Cheat Sheet Series)

For example, imagine a website has a form that changes an email address:

User logged in
      ↓
Browser contains session cookie
      ↓
Attacker tricks user into submitting a request
      ↓
Website receives authenticated request
      ↓
Email address changed

A secure implementation adds another secret value that the attacker cannot easily obtain:

User
 ↓
Authenticated Session
 ↓
CSRF Token
 ↓
Form Submission
 ↓
Server Validation
 ↓
Action Allowed

This guide explains How to Protect Forms Against CSRF using CSRF tokens, secure cookies, SameSite protection, Origin validation, PHP examples, AJAX requests, WordPress considerations, common mistakes, and a practical security checklist.

What Is CSRF?

Before learning How to Protect Forms Against CSRF, let’s understand the attack.

Cross-Site Request Forgery occurs when an attacker causes a victim’s browser to send an unwanted state-changing request to a trusted website.

Suppose a website contains:

POST /change-email

and expects:

email=user@example.com

If authentication relies on a session cookie, the browser may automatically include that cookie with the request.

An attacker could attempt to create a malicious page that causes the victim’s browser to submit the request.

The attacker’s website does not necessarily need to read the response. It only needs the target server to accept the forged request.

OWASP describes CSRF as an attack where a malicious website or other attacker-controlled content tricks an authenticated browser into performing an unwanted action against a trusted site. (OWASP Cheat Sheet Series)

Why Is CSRF Dangerous?

Learning How to Protect Forms Against CSRF matters because a successful attack can potentially perform any action available to the victim’s account.

Depending on the application, this could include:

• Changing an email address
• Changing account settings
• Updating a password
• Adding an address
• Creating content
• Deleting content
• Making a purchase
• Changing permissions
• Transferring funds
• Performing administrative actions

The severity depends on the privileges of the victim.

For example:

Normal User
   ↓
CSRF
   ↓
Change Profile Information

may have limited impact.

But:

Administrator
   ↓
CSRF
   ↓
Create Privileged Account

could be extremely serious.

Therefore, How to Protect Forms Against CSRF becomes especially important for sensitive and administrative actions.

How to Protect Forms Against CSRF With CSRF Tokens

The most common approach to How to Protect Forms Against CSRF is using a CSRF token.

A CSRF token is a random, unpredictable value generated by the server.

The server gives the legitimate user a token:

Server
  ↓
Generate Random Token
  ↓
Display Form
  ↓
User Submits Token
  ↓
Server Verifies Token

For example:

<input type="hidden"
       name="csrf_token"
       value="RANDOM_SECRET_VALUE">

When the form is submitted, the server checks whether the submitted token matches the expected token.

If it doesn’t match:

Request
  ↓
CSRF Token Invalid
  ↓
Reject Request

OWASP recommends server-generated CSRF tokens that are unique, secret, and unpredictable. (OWASP Cheat Sheet Series)

How to Protect Forms Against CSRF Using the Synchronizer Token Pattern

The Synchronizer Token Pattern is one of the most widely used CSRF defenses.

The basic architecture is:

                Server Session
                     ↓
               CSRF Token
                     ↓
              Rendered Form
                     ↓
               User submits
                     ↓
             Server validates
                     ↓
               Action allowed

The token is associated with the user’s session.

For example:

$_SESSION['csrf_token'] = bin2hex(random_bytes(32));

The form can then contain:

<input type="hidden"
       name="csrf_token"
       value="<?= htmlspecialchars($_SESSION['csrf_token'], ENT_QUOTES, 'UTF-8') ?>">

When the request arrives:

if (
    !isset($_POST['csrf_token']) ||
    !hash_equals($_SESSION['csrf_token'], $_POST['csrf_token'])
) {
    http_response_code(403);
    exit('Invalid CSRF token.');
}

This provides a simple example of How to Protect Forms Against CSRF in PHP.

How to Protect Forms Against CSRF in PHP

PHP does not automatically protect every custom form from CSRF. PHP’s own documentation states that applications need to implement CSRF protection themselves, although many frameworks provide built-in mechanisms. (PHP)

A basic PHP implementation can begin with a secure session:

<?php

session_start();

if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] = bin2hex(
        random_bytes(32)
    );
}

Then create the form:

<form method="POST" action="/update-profile.php">

    <input
        type="hidden"
        name="csrf_token"
        value="<?= htmlspecialchars(
            $_SESSION['csrf_token'],
            ENT_QUOTES,
            'UTF-8'
        ) ?>"
    >

    <input
        type="text"
        name="display_name"
    >

    <button type="submit">
        Save Changes
    </button>

</form>

On the server:

if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
    http_response_code(405);
    exit('Method not allowed.');
}

$submittedToken = $_POST['csrf_token'] ?? '';

if (
    empty($_SESSION['csrf_token']) ||
    !hash_equals($_SESSION['csrf_token'], $submittedToken)
) {
    http_response_code(403);
    exit('Invalid CSRF token.');
}

The important principle is that token validation must happen on the server.

Client-side JavaScript validation alone is not CSRF protection.

How to Protect Forms Against CSRF With Secure Random Tokens

A CSRF token must be unpredictable.

In PHP, use:

random_bytes(32)

and convert the result into a suitable representation:

$token = bin2hex(random_bytes(32));

Avoid predictable values such as:

$token = time();

or:

$token = $username;

or:

$token = md5($username);

The purpose of the token is to prove that the request came through a legitimate application flow.

OWASP specifically recommends generating CSRF tokens using a cryptographically secure random mechanism. (OWASP Cheat Sheet Series)

How to Protect Forms Against CSRF With Token Validation

Generating a token is not enough.

You must validate it when the request arrives.

A simple validation process is:

Request received
      ↓
Token present?
   /        \
 No          Yes
 ↓            ↓
Reject     Compare token
              ↓
          Match?
          /    \
        No      Yes
        ↓        ↓
      Reject   Continue

Use a safe comparison function such as PHP’s:

hash_equals()

For example:

if (!hash_equals(
    $_SESSION['csrf_token'],
    $_POST['csrf_token'] ?? ''
)) {
    http_response_code(403);
    exit('CSRF validation failed.');
}

This is preferable to implementing your own comparison logic.

How to Protect Forms Against CSRF for POST Requests

State-changing actions should generally use appropriate HTTP methods such as:

POST
PUT
PATCH
DELETE

rather than:

GET

For example, don’t design a destructive operation like:

GET /delete-account

A better design is:

POST /delete-account

with CSRF protection.

OWASP explicitly recommends not using GET requests for state-changing operations. (OWASP Cheat Sheet Series)

This is an important part of How to Protect Forms Against CSRF.

How to Protect Forms Against CSRF by Avoiding State Changes With GET

A URL such as:

https://example.com/delete?id=123

can potentially be triggered simply by navigating to it.

For example, an attacker could embed a link or resource that causes the browser to request the URL.

Instead:

GET
 ↓
Read information

should generally be used for safe operations, while:

POST
 ↓
Change information

should be used for state-changing actions.

Even POST requests still require CSRF protection when the authentication model is vulnerable to CSRF.

How to Protect Forms Against CSRF With SameSite Cookies

SameSite is an important additional CSRF defense.

A cookie can be configured with:

SameSite=Lax

or:

SameSite=Strict

The browser then applies restrictions to when the cookie is sent in cross-site contexts.

PHP supports the SameSite attribute for session cookies. PHP’s documentation describes Lax and Strict settings as additional measures that can mitigate CSRF vulnerabilities. (PHP)

For example, PHP session configuration can include:

session.cookie_secure = On
session.cookie_httponly = On
session.cookie_samesite = Lax

For applications that can tolerate stricter behavior:

session.cookie_samesite = Strict

However, SameSite should generally be treated as defense in depth rather than your only CSRF defense. OWASP recommends combining it with CSRF tokens in many applications. (OWASP Cheat Sheet Series)

How to Protect Forms Against CSRF With Secure Session Cookies

CSRF protection is closely connected to session security.

A secure session cookie should generally use:

Secure
HttpOnly
SameSite

For example:

Set-Cookie: PHPSESSID=...; Secure; HttpOnly; SameSite=Lax

Secure

The cookie is sent only over HTTPS.

HttpOnly

JavaScript cannot directly read the session cookie.

SameSite

The browser restricts certain cross-site cookie transmission.

PHP recommends HttpOnly for session identifiers and recommends Secure when the application is accessible only over HTTPS. (PHP)

These controls complement CSRF tokens.

How to Protect Forms Against CSRF With Origin Validation

Another useful defense is checking the Origin header on sensitive requests.

For example:

Origin: https://example.com

The server can compare the origin against the expected application origin.

Conceptually:

$allowedOrigin = 'https://example.com';

if (
    isset($_SERVER['HTTP_ORIGIN']) &&
    $_SERVER['HTTP_ORIGIN'] !== $allowedOrigin
) {
    http_response_code(403);
    exit('Invalid origin.');
}

In production, the expected origin should come from trusted configuration rather than being blindly derived from attacker-controlled request data.

OWASP recommends origin verification as an additional CSRF defense. (OWASP Cheat Sheet Series)

How to Protect Forms Against CSRF With the Referer Header

The Referer header can sometimes provide another signal about where the request originated.

For example:

Referer: https://example.com/account

A server can verify that the origin is trusted.

However, the Referer header may be absent or modified by privacy controls.

Therefore, it should not blindly replace CSRF tokens in applications where stronger protection is required.

OWASP recommends checking the Origin header when available and using the Referer as a fallback when appropriate. (OWASP Cheat Sheet Series)

How to Protect Forms Against CSRF With Fetch Metadata

Modern browsers provide Fetch Metadata request headers.

One important header is:

Sec-Fetch-Site

Possible values include:

same-origin
same-site
cross-site
none

A server can use this information as an additional signal.

For example:

Sec-Fetch-Site: cross-site
       ↓
State-changing request
       ↓
Potential CSRF
       ↓
Reject or require additional validation

OWASP recommends Sec-Fetch-Site as a useful signal for identifying obvious cross-site requests, while also recommending fallback mechanisms for clients that do not provide Fetch Metadata headers. (OWASP Cheat Sheet Series)

This can strengthen How to Protect Forms Against CSRF, but it should be implemented carefully.

How to Protect Forms Against CSRF in AJAX Requests

Modern websites often submit forms using JavaScript instead of traditional HTML forms.

For example:

fetch('/update-profile', {
    method: 'POST',
    body: JSON.stringify({
        name: 'John'
    })
});

The request can include a CSRF token in a custom header:

fetch('/update-profile', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'X-CSRF-Token': csrfToken
    },
    body: JSON.stringify({
        name: 'John'
    })
});

The server then validates:

X-CSRF-Token
      ↓
Server
      ↓
Compare With Expected Token
      ↓
Valid?

OWASP recommends custom request headers as a suitable approach for AJAX/API requests, particularly because browsers apply cross-origin restrictions to such requests. (OWASP Cheat Sheet Series)

How to Protect Forms Against CSRF in JSON APIs

JSON APIs often use:

Content-Type: application/json

instead of traditional form encoding.

For cookie-authenticated APIs, you still need to consider CSRF.

A common pattern is:

POST /api/profile

X-CSRF-Token: RANDOM_TOKEN

Content-Type: application/json

The backend verifies the token before processing the request.

However, if the API uses an authentication mechanism that does not automatically attach credentials to cross-site browser requests, the CSRF threat model may be different.

Always evaluate how authentication credentials are transmitted.

How to Protect Forms Against CSRF With the Double-Submit Cookie Pattern

Another approach is the Double-Submit Cookie pattern.

The general idea is:

CSRF Token → Cookie
CSRF Token → Request Header/Form

The server checks that the values correspond.

However, not all double-submit implementations are equally secure.

OWASP recommends a signed, session-bound double-submit cookie rather than relying on a naive implementation. (OWASP Cheat Sheet Series)

This approach can be useful for stateless architectures where maintaining server-side CSRF state is undesirable.

For beginners, a synchronizer token stored in the server-side session is usually easier to understand and implement correctly.

How to Protect Forms Against CSRF in WordPress

WordPress provides a built-in concept called nonces that developers commonly use to help protect actions and forms from CSRF.

For example, a WordPress form can include:

<?php wp_nonce_field(
    'update_profile',
    'profile_nonce'
); ?>

The generated form contains a hidden value.

When processing the request:

if (
    !isset($_POST['profile_nonce']) ||
    !wp_verify_nonce(
        $_POST['profile_nonce'],
        'update_profile'
    )
) {
    wp_die('Security check failed.');
}

For authorization, nonce verification should be combined with capability checks.

For example:

if (!current_user_can('edit_posts')) {
    wp_die('You are not allowed to perform this action.');
}

A nonce is not a replacement for authentication or authorization.

When working with WordPress, also use appropriate sanitization, validation, and escaping.

How to Protect Forms Against CSRF in Laravel

If you are using Laravel, do not create a custom CSRF implementation unless you have a specific reason.

Laravel provides built-in CSRF protection for web routes.

A Blade form can include:

@csrf

This generates the appropriate hidden token.

The framework then validates the token for protected requests.

The general principle is:

Laravel
 ↓
Generate CSRF Token
 ↓
Add Token to Form
 ↓
Validate Automatically
 ↓
Process Request

The key lesson is to use your framework’s built-in CSRF protection whenever it is available and correctly configured.

OWASP explicitly recommends checking whether the framework already provides CSRF protection before building a custom implementation. (OWASP Cheat Sheet Series)

How to Protect Forms Against CSRF in React and Other Frontends

React itself does not automatically provide complete server-side CSRF protection.

If a React application communicates with a cookie-authenticated backend, the backend must implement an appropriate CSRF defense.

A common approach is:

Backend
 ↓
CSRF Token
 ↓
Frontend
 ↓
Custom Header
 ↓
Backend Validation

For example:

fetch('/api/profile', {
    method: 'POST',
    credentials: 'include',
    headers: {
        'Content-Type': 'application/json',
        'X-CSRF-Token': csrfToken
    },
    body: JSON.stringify(data)
});

The backend remains responsible for deciding whether the token is valid.

Do not assume that using React automatically prevents CSRF.

How to Protect Forms Against CSRF in Single-Page Applications

Single-page applications often use:

• React
• Vue
• Angular
• Axios
• Fetch API

If authentication uses cookies, CSRF protection still needs to be considered.

A common architecture is:

Login
 ↓
Secure Session Cookie
 ↓
CSRF Token
 ↓
Frontend
 ↓
POST / PUT / PATCH / DELETE
 ↓
CSRF Header
 ↓
Server Validation

For AJAX requests, a custom CSRF header can be automatically added to state-changing requests.

For example:

const csrfSafeMethods = [
    'GET',
    'HEAD',
    'OPTIONS'
];

async function apiRequest(url, options = {}) {
    const method = (
        options.method || 'GET'
    ).toUpperCase();

    const headers = {
        ...(options.headers || {})
    };

    if (!csrfSafeMethods.includes(method)) {
        headers['X-CSRF-Token'] = csrfToken;
    }

    return fetch(url, {
        ...options,
        headers
    });
}

The server should still validate the token.

How to Protect Forms Against CSRF by Using the Correct HTTP Methods

A secure application should clearly separate safe and state-changing operations.

Safe operations

GET
HEAD
OPTIONS

These should not change application state.

State-changing operations

POST
PUT
PATCH
DELETE

These should receive CSRF protection when the authentication mechanism makes the application vulnerable to CSRF.

OWASP specifically recommends protecting state-changing requests and avoiding state changes through GET. (OWASP Cheat Sheet Series)

How to Protect Forms Against CSRF for Sensitive Actions

Not all actions have the same risk.

For highly sensitive operations, consider additional controls such as:

• Password reauthentication
• MFA
• One-time confirmation
• Transaction confirmation
• User interaction
• Additional authorization checks

For example:

Change Password
      ↓
CSRF Token
      ↓
Current Password
      ↓
MFA
      ↓
Change Password

OWASP recommends additional user-interaction-based defenses for highly sensitive operations such as password changes and financial transactions. (OWASP Cheat Sheet Series)

How to Protect Forms Against CSRF and XSS

CSRF protection and XSS protection are related but different.

CSRF

Tricks a browser into sending an unwanted request.

XSS

Allows attacker-controlled JavaScript to execute in the application’s context.

A serious XSS vulnerability can potentially bypass many CSRF protections because malicious JavaScript running within the trusted origin may be able to access application data and submit legitimate-looking requests.

OWASP explicitly warns that XSS can defeat CSRF mitigation techniques. (OWASP Cheat Sheet Series)

Therefore:

CSRF Protection
       +
XSS Prevention
       +
Secure Authentication
       +
Authorization

should be used together.

You can also connect this article with your internal guide:

How to Configure WordPress Security Headers

for additional browser-level security controls.

How to Protect Forms Against CSRF by Validating User Permissions

A CSRF token does not determine whether a user is authorized to perform an action.

For example:

if (!hash_equals(
    $_SESSION['csrf_token'],
    $_POST['csrf_token'] ?? ''
)) {
    exit('Invalid token.');
}

Even after the token passes, you should still verify permissions:

if (!$currentUserCanEdit) {
    http_response_code(403);
    exit('Access denied.');
}

The secure architecture is:

Authentication
      ↓
CSRF Validation
      ↓
Authorization
      ↓
Input Validation
      ↓
Action

This layered model is important when learning How to Protect Forms Against CSRF.

How to Protect Forms Against CSRF With Input Validation

CSRF protection does not make submitted data trustworthy.

For example:

$email = $_POST['email'] ?? '';

still requires validation.

You may need:

$email = filter_var(
    $email,
    FILTER_VALIDATE_EMAIL
);

Similarly, validate:

• IDs
• URLs
• Names
• Amounts
• Dates
• File references
• Account numbers
• Product IDs

The security principle is:

CSRF protection proves request intent; it does not validate the request data itself.

How to Protect Forms Against CSRF in PHP: Complete Example

Here is a beginner-friendly PHP example combining session-based CSRF protection with form validation.

Step 1: Start the Session

<?php

session_start();

Step 2: Generate the Token

if (empty($_SESSION['csrf_token'])) {
    $_SESSION['csrf_token'] =
        bin2hex(random_bytes(32));
}

Step 3: Create the Form

<form method="POST" action="update-profile.php">

    <input
        type="hidden"
        name="csrf_token"
        value="<?= htmlspecialchars(
            $_SESSION['csrf_token'],
            ENT_QUOTES,
            'UTF-8'
        ) ?>"
    >

    <label>
        Name
        <input
            type="text"
            name="name"
            required
        >
    </label>

    <button type="submit">
        Update Profile
    </button>

</form>

Step 4: Validate the Request

if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
    http_response_code(405);
    exit('Method not allowed.');
}

$token = $_POST['csrf_token'] ?? '';

if (
    empty($_SESSION['csrf_token']) ||
    !hash_equals($_SESSION['csrf_token'], $token)
) {
    http_response_code(403);
    exit('Invalid CSRF token.');
}

Step 5: Validate the Data

$name = trim($_POST['name'] ?? '');

if ($name === '') {
    exit('Name is required.');
}

if (strlen($name) > 100) {
    exit('Name is too long.');
}

Step 6: Perform the Action

Only after authentication, authorization, CSRF validation, and input validation should the application update the database.

This is a practical example of How to Protect Forms Against CSRF.

How to Protect Forms Against CSRF: Recommended Architecture

A secure form-processing workflow can look like this:

                User
                  ↓
            HTTPS Request
                  ↓
             Session Check
                  ↓
           HTTP Method Check
                  ↓
             CSRF Validation
                  ↓
          Authentication Check
                  ↓
          Authorization Check
                  ↓
          Input Validation
                  ↓
            Business Logic
                  ↓
             Database
                  ↓
              Response

This layered architecture prevents developers from treating CSRF tokens as the only security control.

Common CSRF Protection Mistakes

When learning How to Protect Forms Against CSRF, avoid these mistakes.

1. Only Generating a Token

A token is useless if the server does not validate it.

2. Using Predictable Tokens

Do not use usernames, timestamps, or sequential numbers.

3. Putting CSRF Tokens in URLs

Tokens in URLs can leak through browser history, logs, and referrer information. OWASP specifically advises against transmitting synchronizer tokens in URLs. (OWASP Cheat Sheet Series)

4. Protecting Only the HTML Form

AJAX, API, and alternative endpoints must also be protected.

5. Using GET for State Changes

Avoid operations such as:

GET /delete-account

6. Relying Only on SameSite Cookies

SameSite is valuable defense in depth, but it should not automatically replace CSRF tokens in general-purpose applications.

7. Checking CSRF but Not Authorization

A valid CSRF token does not mean the user has permission to perform the action.

8. Trusting Client-Side JavaScript

Attackers can bypass JavaScript.

9. Ignoring XSS

XSS can undermine CSRF defenses.

10. Building Custom Protection When the Framework Already Provides It

Use well-tested framework functionality where available.

Avoiding these mistakes makes How to Protect Forms Against CSRF much more effective.

How to Protect Forms Against CSRF: Security Checklist

Use this checklist when implementing How to Protect Forms Against CSRF:

• Identify all state-changing requests.
• Do not use GET for state-changing actions.
• Use your framework’s built-in CSRF protection where available.
• Generate unpredictable CSRF tokens.
• Store synchronizer tokens server-side.
• Validate tokens on the backend.
• Use safe token comparison.
• Protect POST requests.
• Protect PUT requests.
• Protect PATCH requests.
• Protect DELETE requests.
• Protect AJAX requests.
• Protect cookie-authenticated APIs.
• Use secure session cookies.
• Enable HTTPS.
• Consider SameSite=Lax or SameSite=Strict.
• Consider Origin validation.
• Consider Fetch Metadata validation.
• Validate user permissions.
• Validate submitted data.
• Protect password changes.
• Protect financial transactions.
• Consider reauthentication for high-risk operations.
• Prevent XSS.
• Never place CSRF tokens in URLs.
• Test requests without tokens.
• Test invalid tokens.
• Test expired sessions.
• Test AJAX requests.
• Test alternative endpoints.

How to Test CSRF Protection

After implementing How to Protect Forms Against CSRF, test the protection rather than assuming it works.

Test 1: Valid Request

Submit the form normally.

Expected:

Valid Token
 ↓
Request Accepted

Test 2: Missing Token

Remove the CSRF token.

Expected:

No Token
 ↓
403 Forbidden

Test 3: Invalid Token

Replace it with a random value.

Expected:

Invalid Token
 ↓
Request Rejected

Test 4: Cross-Site Request

Attempt to submit the request from another origin.

Expected:

Cross-Site Request
 ↓
CSRF Protection
 ↓
Rejected

Test 5: Expired Session

Destroy the user’s session and submit the old form.

Expected behavior should be clearly defined and secure.

Test 6: AJAX Request

Ensure that your JavaScript client sends the required CSRF token/header.

Internal Links for Website Security

You can strengthen your website’s internal linking structure by connecting this guide with related security tutorials:

• How to Implement Secure Password Storage — explains password hashing, salts, Argon2id, bcrypt, and password verification.
• How to Secure File Uploads in PHP — explains secure file validation and upload handling.
• How to Add Login Rate Limiting — explains how to protect authentication endpoints against automated attacks.
• How to Secure WordPress User Accounts — covers account security, MFA, roles, and sessions.
• How to Configure WordPress Security Headers — explains HTTP security headers and browser protections.
• How to Restrict Admin Access on a Website — covers administrator access control and least privilege.
• How to Audit WordPress Plugins for Security Risk — explains how to identify vulnerable WordPress plugins.

Replace these example paths with the exact URLs on your website if necessary.

External Resources for CSRF Protection

For readers who want to learn more about How to Protect Forms Against CSRF, the following authoritative resources are useful.

OWASP CSRF Prevention Cheat Sheet

OWASP Cross-Site Request Forgery Prevention Cheat Sheet

This is the primary reference for CSRF tokens, synchronizer tokens, double-submit cookies, SameSite cookies, Origin validation, Fetch Metadata, and AJAX protection. (OWASP Cheat Sheet Series)

PHP Session Security Documentation

PHP Session Security Documentation

The official PHP documentation explains secure session settings such as HttpOnly, Secure, and SameSite. (PHP)

PHP Session Management

PHP Session Management Security Documentation

This resource discusses session security and specifically notes that applications need to implement CSRF protection. (PHP)

OWASP XSS Prevention

OWASP Cross Site Scripting Prevention Cheat Sheet

This is useful because XSS can undermine CSRF protections, making XSS prevention an important part of the overall security strategy. (OWASP Cheat Sheet Series)

These external resources can be used as standard DoFollow links as long as your CMS or SEO plugin does not automatically add nofollow, ugc, or sponsored attributes.

Frequently Asked Questions

What is CSRF?

CSRF, or Cross-Site Request Forgery, is an attack where an attacker tricks a user’s browser into sending an unwanted request to a website where the user is authenticated.

What is a CSRF token?

A CSRF token is a secret, unpredictable value generated by the application and submitted with a state-changing request. The server validates the token before processing the request.

Are CSRF tokens enough?

CSRF tokens are a major defense, but they should be combined with secure authentication, authorization, HTTPS, secure cookies, XSS prevention, and other appropriate security controls.

Should I use SameSite cookies instead of CSRF tokens?

SameSite cookies are useful defense in depth. For many applications, especially cookie-authenticated applications, you should not assume SameSite alone is sufficient. OWASP recommends combining appropriate defenses based on the application’s threat model. (OWASP Cheat Sheet Series)

Should GET requests have CSRF tokens?

GET requests should generally not change application state. If a GET endpoint does perform a state-changing action, it should be redesigned. OWASP specifically recommends avoiding state changes through GET. (OWASP Cheat Sheet Series)

Can CSRF affect login forms?

Yes. Login CSRF is possible even though the user has not yet authenticated. OWASP documents login CSRF as a separate concern and recommends appropriate protections for login flows. (OWASP Cheat Sheet Series)

Can XSS bypass CSRF protection?

Yes. A sufficiently powerful XSS vulnerability can undermine many CSRF defenses because attacker-controlled JavaScript may operate within the trusted application’s context. (OWASP Cheat Sheet Series)

How do I protect AJAX requests against CSRF?

A common approach is to send a CSRF token in a custom request header, such as:

X-CSRF-Token: RANDOM_TOKEN

The backend must validate that token before processing the request. (OWASP Cheat Sheet Series)

Does PHP automatically protect forms against CSRF?

No. PHP provides session functionality and security-related settings, but custom applications need to implement CSRF protection or use a framework that provides it. (PHP)

Does WordPress protect forms against CSRF?

WordPress provides nonces that developers can use to protect actions and forms. Developers should still perform appropriate capability checks and input validation.

Final Thoughts

How to Protect Forms Against CSRF is an essential part of secure web development, particularly for applications that use browser cookies for authentication.

The fundamental idea is straightforward:

A browser automatically sends authentication information, so the application needs another mechanism to determine whether a state-changing request was intentionally generated by the application.

For many traditional applications, a server-generated CSRF token is an effective solution.

A secure request flow looks like this:

                 User
                  ↓
                HTTPS
                  ↓
          Authentication
                  ↓
           Submit Form
                  ↓
            CSRF Token
                  ↓
         Server Validation
                  ↓
           Authorization
                  ↓
          Input Validation
                  ↓
          Business Logic
                  ↓
             Database

The most important practices in How to Protect Forms Against CSRF are:

1. Use framework-provided CSRF protection whenever available.
2. Generate unpredictable CSRF tokens.
3. Validate tokens on the server.
4. Protect all state-changing requests.
5. Do not use GET for state-changing operations.
6. Secure session cookies with Secure, HttpOnly, and an appropriate SameSite value.
7. Consider Origin and Referer validation.
8. Consider Fetch Metadata as an additional defense.
9. Protect AJAX and cookie-authenticated API requests.
10. Always perform authorization checks.
11. Validate submitted data.
12. Protect sensitive actions with reauthentication or MFA where appropriate.
13. Prevent XSS.
14. Never place CSRF tokens in URLs.
15. Test missing, invalid, and cross-site requests.

For beginners, the most important lesson is that CSRF protection is not just adding a hidden field to an HTML form. The server must generate a secure token, the legitimate client must submit it, and the backend must verify it before performing the requested action.

When these controls are combined with secure sessions, HTTPS, proper authorization, input validation, and XSS prevention, How to Protect Forms Against CSRF becomes a practical and repeatable part of a secure web-development workflow.