Using a Web Application Firewall, or WAF, is increasingly commonplace in the modern web development environment. SilverStripe Platform is easily configurable to be able to support the use of WAFs like Incapsula and Cloudflare.
How a WAF works
A WAF will sit between the user and the server, helping to mitigate attacks, serve cached content in a distributed way, and overall increase performance for the site. This requires a slightly different setup for DNS - rather than point your DNS entries directly at the server or Elastic Load Balancer (ELB), you will point it at the CNAME and A records provided by the WAF provider. This will then pass the traffic through to the origin server, which will be configured as your SilverStripe Platform environment. If the SilverStripe team is handling your WAF configuration, this will be taken care of for you, and your DNS settings will be visible in your “Domains” tab. Otherwise, feel free to confirm how you should set up your own WAF with the Support team.
Using WAFs with virtual stacks
The recommended practice for virtual stacks is to have a separate site licence for each virtual stack. This is also useful for separating caching policies, traffic monitoring and access by virtual stack.
Reusing WAF for virtual stacks
As virtual stacks are all on the same server, they will all have the same origin server endpoint.
If you have an Imperva WAF - All non-SSL traffic will be able to use a single site license for your configured WAF However, if any of your virtual stacks are intending to use an SSL certificate for HTTPS, they will require a separate site license or you will need to ensure your one SSL certificate covers all base stack and virtual stack domains.
If you have a Cloudflare WAF - You must obtain a separate license or request a configuration for each of the Vstack domains.
Virtual stacks without WAF
Base/Virtual stacks with WAF and Virtual stacks without one cannot coexist on one instance. Once WAF support is enabled, all virtual stacks on the instance must be set up to use one. Enabling WAF limits access to the stack to only allow connections from the WAF appliance; this means that traffic cannot bypass the WAF.
Default WAF configuration
If you are using a SilverStripe Platform-provided WAF, it is important to know how this affects the way your site is cached, and responds to headers you will be sending. Our default configuration will block any requests that are detected as Cross Site Scripting (XSS) attempts, or any that threaten SQL Injection (SQLI).
In terms of caching, the default configuration is Static Only - this will cache according to standard HTTP headers. Incapsula will also comply with no-cache, max-age and Vary: User-Agent headers.
Incapsula also implements some Content Optimization features. The configuration options selected by default are:
- Async Validation
- Minify CSS
- Minify HTML
- Compress JPEG
- Compress PNG
- “On the fly” (GZIP) compression
We do not recommend, or configure by default, compression of JavaScript via WAF or CDN. Compression of JavaScript in this way can lead to issues with already compressed files, such as those generated by compiling React or Vue.