Website Static Content Caching

Service - CDN for Websites

CDN for websites solves the following problems:

• Reduced load on the origin server hosting the website
• Increased loading speed for static content: images, videos, scripts, fonts, styles, etc.
• DDoS attack mitigation through distributed servers
• Protection against application attacks: injections, XSS, etc.
• Automatic issuance and renewal of SSL/TLS certificates
• Automatic scaling during traffic spikes

Two CDN integration options are available for websites (domains):

• Via domain delegation
• Via CNAME record creation

Domains

The system creates and configures domain objects for caching website static files. These are categorized by type.

Domain Types

• delegated
• cname

Delegation Setup

To enable CDN via delegation, you'll need the website's domain name and 1-2 IP addresses.
After activation, all static content will be served through CDN servers closest to end users.

Pros:

• Static content served via CDN immediately after activation
• No additional actions required

Cons:

• Requires domain delegation to specified DNS provider

CNAME Setup

To enable CDN via CNAME, only the domain name is required.
After activation, you'll receive a special domain name - requests to it will serve static content through nearest CDN servers. Requests to the primary domain won't be cached. To use your own domain name for static distribution, you need to upload an SSL/TLS certificate for this domain. After uploading the certificate, create a CNAME record in your DNS, where the record name is the required domain name for static distribution via CDN, and the record content is a special domain name generated by the system and issued during creation.

Pros:

• No domain delegation required
• Option to create dedicated static content subdomain (CNAME for provided domain), e.g., example.com (primary) and cdn.example.com (static)

Cons:

• Website modifications required to properly serve static content via CNAME

TLS/SSL Certificates

Any domain type can use free Let's Encrypt certificates.
These certificates auto-renew every 60 days.
It is also possible to upload your own certificate, but you will have to update it manually.

Website Protection with WAF

Web Application Firewall - application-level protection. WAF sits between your website and users, analyzing all requests (both legitimate and malicious) and filtering out bad traffic. This blocks requests from bots, hackers, spammers etc., preventing site overload/compromise.

WAF uses OWASP Core Rule Set (CRS). For details see link.

The waf object attaches to domains as secondary: domain.waf

Operation Modes

WAF has three modes: disabled, enabled, and detection-only (logs threats without blocking).

How It Works

WAF uses OWASP Core Rule Set. Each rule has an Anomaly Score (threat level) and type. Example: Score - 5, type - CRITICAL.

Default anomaly types/values:

• CRITICAL - 5
• ERROR - 4
• WARNING - 3
• NOTICE - 2

Incoming requests and outgoing responses are evaluated against attack patterns. When rules trigger, their scores accumulate separately for requests/responses. The request is blocked when either cumulative score exceeds the threshold (default: 5).

Paranoia Level

Adjusts rule set aggressiveness. Two configurable levels: execution (detection-only) and blocking (default: 1 each). Execution level never blocks requests, only logs triggers.
Higher levels increase false positives - legitimate requests may be blocked (requires custom rule exceptions - contact support to enable custom mode).

Level 1

Basic security with minimal false positives. Suitable for all internet-facing HTTP servers.

Level 2

For handling real user data (e.g., e-commerce). Some false positives expected.

Level 3

Online-banking grade security with frequent false positives.

Level 4

Maximum (paranoid) security. Expect numerous false positives.

Implementation strategy for live sites:

1. Set both levels to 1
2. Verify no false positives occur
3. Increase execution level
4. Add exceptions for any false positives
5. Match blocking level to execution level

Sampling Mode

For gradual WAF implementation, use Sampling Mode (default: 100, range: 1-100). This percentage of traffic undergoes CRS inspection. Lower values reduce security coverage.

Recommended approach: Gradually increase sampling from 1% → 2% → 5% → 10% → 20% → 50% → 100% as rules are validated.

Request Logging

When WAF blocks requests, the system logs event details including:

• Request/response parameters
• Triggered rules
• Threat description
• Additional metadata

Access logs via dedicated API method.

Locations

locations are secondary objects attached to domains, enabling path-specific logic. Examples:

• https://example.com/cached-location - browser caching enabled
• https://example.com/no-cached-location - browser caching disabled

Here, locations are /cached-location and /no-cached-location.

Each location can specify sets of HTTP headers that fine-tune request and response handling.

headers define the response headers that the CDN appends before returning content to end users. Use them to control caching (e.g., Cache-Control), enable extra security policies (X-Frame-Options, Content-Security-Policy), or include diagnostic markers.

request_headers list the headers that the CDN forwards to the origin when requesting the original resource. They help pass routing attributes, A/B testing flags, or other metadata required by the client’s backend systems.

CORS headers (cors_headers) are configured separately (predefined names/quantities). Learn more about CORS.

Cache Management

Each domain supports cache purge/refill methods.
Use these when replacing static files without URL changes.

• Purge: Removes content, repopulated on next requests
• Refill: Forces immediate cache repopulation Partial cache cleanup is possible only for objects whose paths match the specified patterns.

Limit: Once per 30 minutes.

Access Restrictions

Domain-level country-based access control available.

Signed URLs

Signed URLs are temporary unique links that provide access to objects on a site without direct public access. They protect content and allow granting time-limited access for downloading or uploading objects.

A secret key is used to generate a signed URL, which must be securely stored both in our system and by the client. The client generates signed URLs independently. Below is Python 3 code for a function to generate signed URLs.

import binascii
import hashlib
import hmac
import time
from urllib.parse import urlparse

def sign_url(url: str,
             secret_key: str,
             acl: str = "*",
             lifetime: int = 31_536_000,
             ) -> str:
    """
    Generate a signed URL with an expiration token for access control

    Args:
        url (str): URL to be signed
        secret_key (str): Secret key for signing (UTF-8 string)
        acl (str): Access control list, defaults to "*" (all paths)
        lifetime (int): Token lifetime in seconds, defaults to 1 year

    Returns:
        str: Signed URL with token appended as query parameter

    Example usage:
    >>> sign_url(
    ...     url="https://example.com/private/example.jpg",
    ...     secret_key="secret",
    ...     acl="/private/*",
    ...     lifetime=60 * 60 * 7,
    ... )
    'https://example.com/private/example.jpg?token=exp=1759879396~acl=/private/*~hmac=4fdb5e8bd60bbdeca1ddbeb93677de595a02d424e8211a3c0fb17e3735950db4'
    """

    exp = int(time.time() + lifetime)
    token_params = f"exp={exp}~acl={acl}"
    key_hex = secret_key.encode("utf-8").hex()

    token_hmac = hmac.new(
        key=binascii.a2b_hex(key_hex.encode()),
        msg=token_params.encode(),
        digestmod=hashlib.sha256,
    )
    token_digest = token_hmac.hexdigest()
    token = f"{token_params}~hmac={token_digest}"

    if urlparse(url).query:
        return f"{url}&token={token}"

    return f"{url}?token={token}"

The lifetime parameter specifies the validity period of the URL in seconds. The acl parameter is a path pattern specifying which resources the URL grants access to, relative to the base site URL. Examples of acl values:

• * — all files (default)
• /media/private_* — all files in the media folder with prefix private_
• /media/* — all files in the media folder and its subfolders
• /media/example.mp4 — only the file example.mp4 in the media folder

note

The acl applies to the location and must include the location name. For example, to restrict access to the site location https://example.com/private, the acl value would be /private/*

If the client suspects the secret key has been compromised, they can change the key. In that case, all previously issued signed URLs will become invalid, ensuring secure access.

Object Hierarchy

Final hierarchy for website static content caching management:

{
    "domain": {
        "name": "example.com",
        "type": "delegated",
        "ssl_cert": {},
        "waf": {},
        "locations": [
            {
                "headers": [],
                "request_headers": [
                    {
                        "key": "X-Origin-Routing",
                        "value": "beta"
                    }
                ],
                "cors_headers": {}
            }
        ],
        "other_params": "..."
    }
}