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.
Address
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.
Backup
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.
Host Header
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.
Pull Protocol
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).
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 Settings
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
Custom Purge allows you to selectively purge assets from your CDN Cache by specifying a URL or a specific file path.
Purge Everything
Selecting Purge Everything will purge all assets from your CDN Cache.
Cache Handling
Lifetime
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 configurated.
- 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.
Query String Control
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
Gzip Compression
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.
Content Availability
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 Header
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.
Client Browser Policy
Browser Cache TTL
Sets the length of time that client browsers use to locally cache your content. Learn more about this feature here.
CORS Header Support
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 Support
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 StackPath HTTP/2 support does not include Push, and is only used on the connection between the client and the edge. Using HTTP/2 to the origin would in most cases have small to nonexistent performance benefits. HTTP2 is only available for encrypted requests (HTTPS)
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:
- Protect Mode: All policies and rules are engaged as configured. The WAF is actively protecting your site in this mode.
- Monitor 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
Contains the toggles for the default User-Agent policies for the WAF. User agents denote the browser or application level interface that is being used to make an HTTP request. These policies are useful for helping to block various bots.
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). These policies include:
- SQL Injection
- XSS Attacks
- Shellshock
- Remote File Inclusion
- WordPress Ruleset
- Apache Struts Exploit
- Local File Inclusion
- Common Web Application Vulnerabilities
- Web Shell
- Response Header Injection
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. The polices include:
- 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. These policies include:
- 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-Automated & Bot Protection
This set of rules is focused on blocking nefarious bots and other types of non-legitimate automated traffic. These rules include:
- 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. The WAF currently has native polices for the following CMS:
- 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.
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. The options available are as follows:
- Force WWW Connections - Forces a redirect to the www subdomain and host header on all requests
- Robots.txt Support - Offloads robots.txt to the Edge
- Referrer Protection - Restricts access based on user-defined referrer header
- Pseudo Streaming Support - Passes Pseudo streaming from the origin to enable cached Flash content to pseudo stream from the Edge
- URL Caching - Toggle caching of dynamic content based without the need for specifying a file extension. (will cache the dynamic content of your site, and subpages such as yoursite.com/blog)
- Custom Rules - 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.