StackPath Sites offer a nearly infinite amount of customization to be used with almost any use-case imaginable. This flexibility comes by opening up a variety of settings that can be configured. This article is designed to show where some of these settings are, and explain how to use them.
This Article assumes that you have already created a StackPath Site.
Overview Tab
The Overview tab contains the quick-links for settings, analytics, popular features and to enable or disable the services.
Settings Tab
The Settings tab contains all of the settings for configuring an Origin with StackPath's systems. There is a more in-depth guide to all of these settings here for your reference.
Origin
The protocol, domain, and path that we will use to retrieve content from your origin server, this field usually contains the IP address of your server to ensure we have a direct connection.
In the event an origin server experiences failure, a backup origin can be entered. For more information about how backup origins work, please view our article on Origin configuration here.
The Host Header is a request header our system sends to your origin server. By default, this is set to dynamic, but if your server is expecting a specific custom header, you can add that value to your Delivery Domains section, and select it from the drop-down for Host Header.
This setting allows you to give the CDN credentials to use for origin pulls, if your origin is using basic http authentication.
This setting will determine the protocol with which the CDN connects to your origin server. You can choose between HTTP Only, HTTPS Only, or HTTP or HTTPS (if your origin supports both protocols).
With this setting active, the CDN will not connect to the origin unless that the origin has a valid SSL certificate for the requested domain.
This setting enables websocket support through the CDN.
Delivery Domains
This is the list of domains to which StackPath will respond to requests. Add a delivery domain for every domain you wish to use this configuration.
CDN Tab
This is a high-level overview of the CDN Settings as shown in the StackPath Control portal. Please feel free to browse the CDN Articles and Getting Started articles in our KnowledgeBase for all kinds of useful information on leveraging the CDN!
Purge
Custom Purge allows you to selectively purge assets from your CDN Cache by specifying a URL or a specific file path.
Selecting Purge Everything will purge all assets from your CDN Cache.
Cache Handling
Set the maximum length of time that the CDN will cache your content before going back to the origin, or defer to the value passed by your origin.
- Origin Controlled
- The StackPath CDN will honor the cache-control headers.
- Specify CDN TTL
- Static content will be cached (and will not expire) based on the TTL configured.
- Dynamic Content will be cached based on the origin cache-control headers.
- Never Expire
- Static Content will be cached and will not expire.
- Do Not Cache
- Static and Dynamic resources will not be cached, and a request will be sent to the origin server for each request.
Determine how you want StackPath to treat URLs that have a query string portion (a "?" followed by a series of keyword/value pairs represented by "&x=y".
Ignoring the query string means we will cache https://example.com/file.txt?ver=1 and https://example.com/file.txt?ver=2 identically based on which is requested first. "Standard" behavior is that we will cache these 2 URLs distinctly.
This feature enables the CDN to create specific cache keys based on request headers to deliver specific content. Learn more about the functionality of this feature here.
Enable this to reduce the file size of your text-type content, which will improve delivery speeds. You can select a level from 1 (least compressed) to 6 (most compressed) if you're concerned about the CPU impact of decompression for your end-users. For more information about how the StackPath CDN works with gzip, please view our article explaining GZIP compression.
Enable this to keep content in cache beyond its expiration time in case we can't reach your origin. We'll check the origin, and if the file is there, we'll update it. If not we'll serve the expired asset from cache.
Vary is an HTTP response header that allows distinct variations of the same content to be cached using the same URL. The content is selected based on the value of the specified Request header, to ensure the right content is served to the right place.
When enabled the vary header option allows the StackPath CDN to follow your origin server's vary header when making origin pull requests. When Disabled, the CDN will ignore the header when making origin pull requests.
A canonical header tag is used to indicate to search engines which URL of a website is the authoritative source when serving content. This allows search engines to produce uniform results and eliminates duplicate versions from appearing in search engine results, and is considered important for users concerned with search engine optimization.
This feature allows caching of URLs without file extensions. By default, the StackPath CDN caches static content such as images, CSS and Javascript files. When enabling URL Caching, use-cases that desire to cache the entirety of a website's assets (including dynamic content) can be fulfilled.
Client Browser Policy
Sets the length of time that client browsers use to locally cache your content. Learn more about this feature here.
For security reasons, web browsers will prevent Javascript code from making requests to a different origin (e.g. different domain) than the one it's hosted on (e.g. requests from origin1.website.com to origin2.website.com will get blocked).
Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin.
Enabling this feature will send an "Access-Control-Allow-Origin: *" header in the response which will indicate to the client browser which client origins will be allowed to access a resource.
In order to avoid the double CORS error, effective January 2020 StackPath only adds the access-control-allow-origin header for your content if it is not included in your origin server's response. If you configured your site with StackPath prior to January 2020 please disable the CORS setting then re-enable it, to make sure it follows the new behavior.
HTTP/2 is the next generation of web protocol. It has features like binary encoding and multiplexing that make web connections faster and more efficient if your site is designed to make use of them.
Please note that HTTP2 is only available for encrypted requests (HTTPS)
Enabling HTTP/2 Server Push allows for additional assets to be directly pushed to a visitor's browser, without waiting for a request. You can read more about this feature here.
WAF Settings
This is a high-level overview of the CDN Settings as shown in the StackPath Control portal. Please feel free to browse the WAF Articles in our Knowledge Base for all kinds of useful information on leveraging the Web Application Firewall.
WAF Mode
Allows you to toggle to WAF between the two modes that are currently available
All policies and rules are engaged as configured. The WAF is actively protecting your site in this mode.
The WAF will log the requests along with the policies that would have blocked them, but allows all traffic through. This is a useful mode for debugging and dialing-in your WAF policies.
For more information on Monitor mode, please feel free to check out this article.
API URL Configuration
If you're using an API on the same domain that is being protected by the WAF, this will allow that API to be allowed through the WAF. This disables the WAF javascript validation for your API directory so that the WAF does not interfere with your application.
If you'd like to know more about configuring your API with the WAF, please feel free to read this article.
DDoS Protection
This is where you may configure the thresholds at which DDoS Protection is triggered. To learn more about the WAF and L7 DDoS Protection, please check out our article on the WAF and Application-layer DDoS protection.
User Agents
This policy blocks requests in which the request user-agent does not match a known browser
This policy blocks requests in which the HTTP header describing the user-agent (browser and platform) is missing.
NOTE: User-agent policies can block some legitimate traffic from tools like Pingdom, GT Metrix, and Google PageSpeed Insights.
Please keep this in mind when testing your site when the WAF is enabled. It may be necessary to find and enable the respective Known Bot policy for the tool or create a rule to allow these tools through the WAF. The Known Bot policies can be found at the very bottom of the WAF settings tab.
For more information on creating WAF rules, please check out this article.
WAF & OWASP Top Threats
These are the core rules that power our WAF. These are a combination of policies designed by StackPath, as well as top threats that have been recognized by The Open Web Application Security Project(OWASP).
Blocks attempts at accessing your website databases with common SQL exploits.
Blocks attempts at launching cross site scripting attacks from your site.
Block requests which attempt to exploit Bash shell vulnerabilities.
Block attempts to link remote files which may be executed by server-side processes.
Block many common Wordpress exploits.
Block requests which seem targeted at known Apache Struts vulnerabilities.
Block attemps to link local files which may be executed by server-side processes.
Block attempts to access common control panels, configuration scripts, etc.
Block attemps at creating a remote shell connection to the server.
Block attempts at exploiting incomplete input sanitation.
To dive deeper into these and other WAF Policies, please visit our article on How the StackPath WAF Works.
CSRF Attacks
Toggles the option to generate a Cross-Site Request Forgery(CSRF) token and add it to the forms on your site. For more information about Cross-Site Request Forgery and practices to prevent it, please have a read over this informative article by OWASP.
Traffic Sources
These policies check for the source of a request and will block or allow based on real-time threat intelligence for information like IP, source location and more.
- Traffic via TOR Nodes
- Traffic via Proxy Networks
- Traffic from Hosting Services
- Traffic via a VPN
- Convicted Bot Traffic
To dive deeper into these and other WAF Policies, please visit our article on How the StackPath WAF Works.
Behavioral WAF (advanced threat protection)
These policies block or allow traffic based on StackPath's sophisticated user behavior and reputation analysis rules.
- Spam Protection
- Block Probing and Forced Browsing
- Obfuscated Attacks and Zero-Day Mitigation
- Repeated Violations
- Brute-Force Protection
To dive deeper into these and other WAF Policies, please visit our article on How the StackPath WAF Works.
Anti-Automation & Bot Protection
This set of rules is focused on blocking nefarious bots and other types of non-legitimate automated traffic.
- Force Browser Validation on traffic anomalies
- Challenge Automated Clients
- Challenge Headless Browsers
- Anti-Scraping
To dive deeper into these and other WAF Policies, please visit our article on How the StackPath WAF Works.
CMS Protection
These rules are designed to allow the backend functions of Content Management Systems(CMS) such as WordPress, Joomla, Magento, and more to function without being blocked or challenged by your WAF instance.
- WordPress
- MODX
- Joomla
- Magento
- Umbraco
- Drupal
For more information on setting up the WAF with your Content Management System, please check out our article on this topic.
Spam and Abuse
Where the Behavioral WAF rules monitor visitors for suspicious activity and repeated, automated actions, Spam and Abuse focuses on stopping automated form submissions on their first attempt.
To dive deeper into this and other WAF Policies, please visit our article on How the StackPath WAF Works.
Firewall Settings
Allowed IPs
Rules to explicitly allow specific IPs or ranges of IPs through the WAF, regardless of other policy configurations.
Blocked IPs
Rules to explicitly block specific IPs or ranges of IPs through the WAF, regardless of other policy configurations.
Note: These firewall rules are separate from the default WAF Policies and also do NOT count against your Custom Rule allotment. For more information on Blocking and Allowing IPs, please read our article on Whitelisting and Blocking IPs.
Serverless Scripting
In the StackPath Control Panel, this is where any javascript functions you are running at the edge would be configured, monitored and managed.
StackPath's Serverless Scripting is a serverless computing platform that allows you to upload JavaScript scripts and have them automatically deployed within seconds to every StackPath datacenter worldwide.
There, the scripts can interact with every request that comes into your site (or just the requests you define) and do things like modify the request or response bodies, make decisions based on the request headers or a number of additional StackPath headers, make additional fetch queries, or even respond to the request directly without having to send it to your origin. Just a few of the many possible uses are available in our Serverless Scripting support section for you to review.
Please feel free to browse the Serverless Scripting Articles in our Knowledge Base for all kinds of useful information on leveraging javascript functions at the Edge!
If you do not currently leverage Serverless Scripting, you may also subscribe to the service from this tab. For an overview of our Serverless Scripting service, please check out this article.
EdgeSSL
This is the area of the portal where your EdgeSSL Settings are presented. Please feel free to browse the EdgeSSL-related articles in our Knowledge Base for all kinds of useful information.
In the EdgeSSL tab, you can upload, request, and manage the SSL certificate that is on the Edge for your site. There are two main options for using SSL on the StackPath CDN (select each option for an article on using them, respectively):
You can also toggle a switch for Force HTTPS, which would have the CDN apply an automatic redirect to HTTPS
For more information on StackPath SSL options, please read over our SSL Options article
EdgeRules
The Edge Rules are where you can dictate various behavior for traffic that comes to your site via the CDN. Please feel free to browse the Edge Rules articles in our Knowledge Base for all kinds of useful information!
To leverage edge rules, your website must be integrated via Full Site integration. These will not function properly when utilizing a Static Assets integration.Please read our article on managing a StackPath Site for more information on the integration options available to you.
Edge Rules allow you to set conditional triggers to allow the CDN to have control over various types of tasks such as redirects, caching behavior, and much more.
Forces a redirect to the www subdomain and on all non-www requests
Offloads robots.txt to the Edge, allowing it to serve more quickly, and preventing some unwanted bot traffic from hitting your server
Restricts access based on a user-defined referrer header
Passes Pseudo streaming from the origin to enable cached Flash content to pseudo stream from the Edge
Permits caching of dynamic content based without the need for specifying a file extension. This will cache the dynamic content of your site, and subpages such as yoursite.com/blog-post.
Construct custom conditional behaviors on the Edge using If / Then Statements which trigger off of various, user-defined criteria.
For a deeper look into our Edge Rules, please have a look at our Edge Rule articles.