How to use Edge Content Protection

Edge Content Protection (ECP) enforces paywall and entitlement validation at the CDN edge layer through Arc XP’s Edge Integration Framework (EIF). When enabled, content is rendered only after entitlement cookies are validated, ensuring secure and consistent access control.

Content Rendering at the Edge

When a user requests a page, ECP runs through the following flow:

1. Request arrives at Akamai Edge

   The Edge Content Protection module intercepts the request.

2. Exclusion check

   Path patterns are ;-separated and support * / ? wildcards.

   • If an include-paths pattern is configured, requests that do not match it are bypassed.
   • If an exclude-paths pattern matches, the request is bypassed.

3. Entitlement cookie validation

   The module extracts the configured entitlement cookie (default: expiration) and validates it against the rules in Cookie Validation.

4. Variant assignment

   • Valid cookie → the variant is set to the value of the JWT’s Entitlement claim ("1" or "2").
   • Otherwise → the variant segment is removed ({ remove: true }). This only takes effect when the Content Protection edge integration is enabled.

5. Content rendering

   The variant value becomes part of the cache key. Arc XP returns different versions of the page based on the variant. Unauthorized users never receive premium content.

   For example, if you configure your resolvers so variant 2 serves premium content, unauthorized users will not be able to view that content, because they never receive variant 2.

Note

• Validation and variant assignment occur in place at the edge — no redirects. This keeps the response fast and removes redirect-based attack surface (see Security and Best Practices).
• Differentiated rendering depends on PageBuilder resolvers being configured to read the variant query parameter. Without that setup, ECP still sets or removes the variant, but every user receives the same page.

Cookie Validation

ECP parses the entitlement cookie as a compact JWS and checks each rule below. If any rule fails, the variant is removed.

Field	Rule
Header alg	Must be HS256 or HS512
Payload exp	Numeric, in the future
Signature	Verified with the configured HMAC secret
Payload Entitlement	String "1" or "2" (capital E)

Note

Standard claims (iss, sub, aud, iat, nbf) are not validated.

Sample Payload

{
  "Entitlement": "2",
  "exp": 1763035200
}

Configuration Parameters

These are configured in the Delivery Admin UI under Site settings → Edge Integrations → Content Protection.

Parameter	Manifest key	Required?	Example / Default	Notes
Cookie name	EW_PWL_COOKIE_NAME	No	expiration	Must match ^\w+$.
Cookie key	EW_PWL_COOKIE_KEY	Yes	—	HMAC secret. Must match ^\w+$ (no +, /, =).
Include paths	EW_INCLUDE_PATHS	No	—	;-separated wildcard patterns; if set, only matching paths are protected.
Exclude paths	EW_EXCLUDE_PATHS	No	—	;-separated wildcard patterns; matching paths bypass protection.

Generating a Cookie Key

You can generate a key using this command:

openssl rand -hex 32

Caution

Use -hex, not -base64. Base64 output contains +, /, = characters that the cookie-key validation regex (^\w+$) rejects.

Tip

No length is enforced, but a minimum 32-character key is recommended.

Security and Best Practices

• Always use a minimum 32-character HMAC key for cookie verification.
• Handle sign-in flows at the client or origin — ECP enforces inline at the edge and does not redirect unauthorized requests.
• Ensure excluded paths are narrowly defined to prevent unintended bypasses.
• Consider using a hybrid setup to pair server-side protection with client-side personalization or metering.