CSRF protection
Another site can make a visitor's browser post to your application - a hidden form that submits itself - and the browser sends your session cookie along. A CSRF token tells those posts apart from the ones your own forms send: a random value kept in the visitor's session and written into your form, which another site can make the browser send but cannot read.
One setting
With $padCsrf = TRUE in _config/config.php every <form method="post"> of a page gets a hidden padCsrfToken field holding the token, and every POST - and PUT, PATCH and DELETE - that does not bring the token back is answered 403 before any of the application runs. The forms an application already has are protected without a change to them. A form that posts to another site gets no token, and neither does a GET form, whose fields end up in the url.
The {csrf} tag
{csrf} writes the field itself, for a form the page builds some other way, or for an application that leaves $padCsrf off and checks a post by hand with padCsrfValid (). {csrf token} is the bare token, for a script that sends it in an X-CSRF-Token header:
|
PHP |
HTML fragments/csrf_protection_1.pad |
Result |
|---|---|---|
|
- The token is one per session, so two open tabs and the back button keep working. The session starts the first time a token is needed.
- A page carrying a token is never stored in the page cache - it would hand one visitor's token to the next.
- An application that accepts posts from elsewhere on some pages - a webhook - switches
$padCsrfoff for those pages in its_config/config.php, which knows$padPage.