Correctly implement CSRF protection for simple forms

How is a CSRF token securely generated and validated in a simple PHP form?

When the form is displayed, the token is generated using `random_bytes` and stored in the session and a hidden field. The POST request must be from the same active session; the length and value are compared using `hash_equals` before any changes are made, while SameSite and, if necessary, Origin checks provide additional layers.

Cryptographic Randomness

• Cryptographic Randomness – The token has sufficient entropy, is generated server-side, and contains neither user identification nor a guessable time value.

• Session Binding – The sent value is checked against the token stored for the current session and not just for its presence.

• Endpoint Impact Check – Invalid or missing tokens completely stop processing, storage, transmission, and other state changes.

Session Binding

1. Start the session with secure cookie settings and securely encode a sufficiently long token from random_bytes.

2. Output the token in the session state and as a hidden form field without including it in the URL or log.

3. Check the POST method, session, token format, and hash_equals before each action and log errors neutrally.

Practical scenario: "Reusing a global token"

A contact form saves drafts in a session and later sends a request. Both POST routes check their own session proof before saving or sending; a copied request without the appropriate cookie and token ends without partial processing.

Reusing a global token

• Reusing a global token – An identical value for all visitors can be copied from a page and offers no binding to the targeted user.

• Unsafe comparison – Loose comparison, type conversion, or missing length check accepts unexpected values ​​or weakens verification.

• Partial effect before abort – An email is sent or a record is created before the application detects the invalid token.

Endpoint Impact Check

• Proportion of state-changing form routes with mandatory server-side token validation before the first side effect.

• Rejected requests due to missing, expired, or mismatched tokens, with no token value logged.

Which perspectives complement "CSRF protection for PHP forms"?

An in-depth question answered Building a Security and Error Log for Production FormsWhich form events should be logged without creating new data privacy or security risks?

Further Perspectives Use required fields only where they are truly necessary.

If you want to practically implement "CSRF protection for PHP forms," ​​you can refer to Robust Website Systems This focuses on "CSRF protection for state-changing requests" and "cryptographic randomness."

Conclusion: CSRF protection for PHP forms

CSRF protection combines unpredictable value, current session, and early server-side validation. Cookie attributes and header controls complement this combination but do not replace it entirely.

Sources and Further Information

The following official documentation and standards provide the technical classification.

• Cross-Site Request Forgery Prevention Cheat Sheet – OWASPThe OWASP primary source describes synchronized tokens, SameSite, origin verification, and fetch metadata as combinable CSRF countermeasures, including their limitations.

• Session Management Basics – PHP ManualThe official PHP documentation explains secure session cookies, ID regeneration, expiration, and server-side session management for the token context.