Form security#

Whenever you are accepting or asking users to input data to your application there comes an added responsibility that it should be done as safely as possible. Below outlines the things to consider when building your forms.

Cross-Site request forgery (CSRF)#

Silverstripe CMS protects users against Cross-Site Request Forgery (known as CSRF) by adding a SecurityID HiddenField to each Form instance. The SecurityID contains a random string generated by SecurityToken to identify the particular user request vs a third-party forging fake requests.

The SecurityToken automatically added looks something like:

use SilverStripe\Forms\Form;

$form = Form::create(/* ... */);
echo $form->getSecurityToken()->getValue();

// 'c443076989a7f24cf6b35fe1360be8683a753e2c'

This token value is passed through the rendered Form HTML as a HiddenField.

<input type="hidden" name="SecurityID" value="c443076989a7f24cf6b35fe1360be8683a753e2c" class="hidden"  />

The token should be present whenever a operation has a side effect such as a POST operation.

It can be safely disabled for GET requests as long as it does not modify the database (i.e. a search form does not normally require a security token).

$form = Form::create(/* ... */);
$form->disableSecurityToken();

Strict form submission#

To reduce attack exposure forms are limited, by default, to the intended HTTP verb (mostly GET or POST). Without this check, forms that rely on GET can be submitted via POST or PUT or vice-versa potentially leading to application errors or edge cases. If you need to disable this setting follow the below example:

$form = Form::create(/* ... */);

$form->setFormMethod('POST');
$form->setStrictFormMethodCheck(false);

// or alternative short notation..
$form->setFormMethod('POST', false);

Spam and bot attacks#

Silverstripe CMS has no built-in protection for detailing with bots, captcha or other spam protection methods. This functionality is available as an additional Spam Protection module if required. The module provides an consistent API for allowing third-party spam protection handlers such as Recaptcha to work within the Form API.

Data disclosure through HTTP caching#

Forms, and particularly their responses, can contain sensitive or user-specific data. Forms can prepopulate submissions when a form is redisplayed with validation errors, and they by default contain CSRF tokens unique to the user's session. This data can inadvertently be stored either in a user's browser cache or in an intermediary cache such as a CDN or other caching-proxy. If incorrect Cache-Control headers are used, private data may be cached and accessible publicly through the CDN.

To ensure this doesn't happen Silverstripe CMS adds Cache-Control: no-store, no-cache, must-revalidate headers to any forms that have validators or security tokens (all of them by default) applied to them; this ensures that CDNs (and browsers) will not cache these pages. See Performance: HTTP Cache Headers.

Related documentation#

• Security

API documentation#

• SecurityToken