Security & best practices
- Cross-Origin Resource Sharing (CORS)
- Ensure that requests to your API come from a whitelist of origins
- CSRF protection
- Protect destructive actions from cross-site request forgery
- Strict HTTP method checking
- Ensure requests are GET or POST
- Ensure your GraphQL api is only accessible to provisioned users
CSRF tokens (required for mutations)
Even if your graphql endpoints are behind authentication, it is still possible for unauthorised users to access that endpoint through a CSRF exploitation. This involves forcing an already authenticated user to access an HTTP resource unknowingly (e.g. through a fake image), thereby hijacking the user's session.
In the absence of a token-based authentication system, like OAuth, the best countermeasure to this is the use of a CSRF token for any requests that destroy or mutate data.
By default, this module comes with a
CSRFMiddleware implementation that forces all mutations to check
for the presence of a CSRF token in the request. That token must be applied to a header named
In SilverStripe, CSRF tokens are most commonly stored in the session as
SecurityID, or accessed through
SecurityToken API, using
Queries do not require CSRF tokens.
Disabling CSRF protection (for token-based authentication only)
If you are using HTTP basic authentication or a token-based system like OAuth or JWT,
you will want to remove the CSRF protection, as it just adds unnecessary overhead. You can do this by setting
the middleware to
SilverStripe\Core\Injector\Injector: SilverStripe\GraphQL\QueryHandler\QueryHandlerInterface.default: class: SilverStripe\GraphQL\QueryHandler\QueryHandler properties: Middlewares: csrf: false