Securing a Cascade site: WAF, headers, and hardening

People sometimes assume a Cascade site needs little security work because it serves static files. It is true that there is no login form on the public site, no database answering visitors, and no plugins running on each request. That removes whole categories of attack. But a static site still has a web server, a publishing channel, forms and search, third-party scripts, and a reputation worth protecting. Security here is about closing the gaps that remain, and they are specific and fixable.

The real attack surface

Security headers worth setting

Security headers are instructions the server sends to the browser. They cost nothing in performance and close off several classes of attack.

• Strict-Transport-Security: tells browsers to use https only, so a visitor on public Wi-Fi cannot be quietly downgraded.
• Content-Security-Policy: lists where scripts, styles, and frames may load from. It is the strongest defense against injected scripts and the one that needs the most care, because an overly strict policy breaks legitimate embeds. Roll it out in report-only mode first.
• X-Content-Type-Options: nosniff: stops browsers from guessing file types in unsafe ways.
• Referrer-Policy: limits how much of your URLs is passed to other sites.
• Frame protection (a frame-ancestors directive, or X-Frame-Options): stops other sites from embedding your pages to trick visitors into clicking.
• Permissions-Policy: turns off browser features you do not use, such as camera or geolocation.

You can see which headers your site sends with:

curl -sI https://www.example.edu/ | grep -iE "strict-transport|content-security|x-content-type|referrer-policy|x-frame|permissions-policy"

Missing lines are the headers not being set.

The web application firewall

A web application firewall (WAF) sits in front of the site and inspects requests before they reach it. Managed rule sets block common attack patterns, including the OWASP Top 10 categories such as SQL injection and cross-site scripting, and are updated by the provider as new techniques appear. Rate limits slow down scrapers and brute-force attempts against forms. Always-on DDoS protection at the network edge absorbs volumetric floods. For a static site, the WAF matters most for the dynamic services and for keeping abusive traffic off the origin.

A hardening checklist for the publish target

1. Publish over an encrypted transport (SFTP with key authentication, FTPS, or S3 with scoped credentials), never plain FTP.
2. Give the publishing account write access only to the web root it needs, nothing more.
3. Rotate transport credentials when staff with access leave.
4. Turn off directory listings.
5. Remove or block old test folders, backup files, and anything named old, bak, or test.
6. Review third-party scripts once a term. Remove the ones nobody can explain.
7. Put spam protection and rate limits on every form.
8. Make sure the origin only accepts traffic from the CDN, so attackers cannot bypass the WAF.

If you suspect a compromise

Signs include pages you did not publish, unexpected redirects to other sites, a browser or search engine warning about your domain, or files appearing in the web root. Do not delete anything and do not republish over it yet. Note what you saw and when, take screenshots, and report it immediately. Evidence on the server shows how it happened, which is what prevents it from happening again. A republish from Cascade restores clean content once the entry point is closed.

How eWay secures Cascade sites

eWay configures the publish target with defense in depth. Network isolation and tightly scoped security groups, a WAF with managed OWASP rules plus custom rules, and always-on DDoS protection sit in front of a hardened origin that accepts traffic only through the CDN. TLS 1.2 or later is enforced with HTTP redirected to HTTPS, data is encrypted at rest, and security headers are set at the edge. Administrative access requires multi-factor authentication and is logged. Operating systems are patched on a regular cycle, critical fixes go out ahead of schedule, and vulnerability scanning runs continuously.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• The URL and what looked wrong, such as unexpected content, a redirect, or a browser warning
• For a suspected compromise: when you noticed, and do not delete anything yet, because evidence matters
• For header or policy changes: which third-party services the site must keep loading

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. A suspected security incident is a P1: submit the ticket, then call 877-487-3929 (8am to 5pm ET, Monday to Friday). See how to request support for all the options. Related reading: SSL certificates and domain management and single sign-on for Cascade authors. More at Cascade Website Hosting.