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 protect users against [Cross-Site Request Forgery](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
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
SecurityToken automatically added looks something like:
$form = new Form(..); echo $form->getSecurityToken()->getValue(); // 'c443076989a7f24cf6b35fe1360be8683a753e2c'
<input type="hidden" name="SecurityID" value="c443076989a7f24cf6b35fe1360be8683a753e2c" class="hidden" />
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 = new Form(..); $form->disableSecurityToken();
Do not disable the SecurityID for forms that perform some modification to the users session. This will open your
application up to
CSRF security holes.
Strict Form Submission
Forms should be limited to the intended HTTP verb (mostly
POST) to further reduce attack exposure. Without
this check, forms that rely on
GET can be submitted via
PUT or vice-versa potentially leading to
application errors or edge cases.
$form = new Form(..); $form->setFormMethod('POST'); $form->setStrictFormMethodCheck(true); // or alternative short notation.. $form->setFormMethod('POST', true);
SilverStripe 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 and Mollom to work within the
Data disclosure through HTTP Caching (since 3.7.0)
Forms, and particularly their responses, can contain sensitive data (such as when data is pre-populated or re-posted due
to validation errors). 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-Conrol headers are used, private data may be cached and
accessible publicly through the CDN.
To ensure this doesn't happen SilverStripe 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.