Edge access policy

Edge access policy is the set of rules that decide, before content is served, whether a request is allowed, denied, or redirected. It is coarser than the WAF’s per-request scoring and applies to every request on a resource: geography, referrer, source address, and method. Getting the default action and the exception model right is what keeps the policy maintainable as a platform grows. See Web application and API protection for the deeper inspection layer that sits on top.

Geo policy

Geography rules restrict or vary access by the viewer’s coarse location. On adult platforms they serve several purposes:

• Licensing and distribution windows where content rights are territorial.
• Jurisdictional restrictions where serving a region carries obligations you have chosen not to meet.
• Routing and language choices that are convenience, not control.

Two cautions. First, IP geolocation is approximate — VPNs, mobile carriers, and corporate egress make the viewer’s apparent country unreliable, so never treat geo as identity. Second, a geo block is a blunt instrument; document why each rule exists and who owns it, because stale geo rules silently lose traffic. The decision of where you are legally permitted to serve, and the age/consent rules that go with it, remains yours.

Referrer and hotlink rules

A referrer rule inspects the Referer header and allows, denies, or redirects based on where the request originated. Typical use: allow requests with no referrer (direct navigation, apps) and from your own domains, and block or redirect requests from third-party pages embedding your media. The limits matter:

• Referer is spoofable and can be stripped by privacy settings, so it is deterrence, not authentication.
• A strict “must have an allowed referrer” rule breaks app clients and direct downloads. Decide explicitly whether empty referrer is allowed.
• For media that costs real egress, pair referrer rules with signed URLs — see Bot management and scraping for why that is the actual defence.

IP allow and deny

Source-address rules are useful for a narrow set of jobs: allowlisting partner and internal ranges, denying known-bad networks, and locking down admin or preview surfaces so they are reachable only from trusted addresses. Their weakness is well known — residential-proxy botnets rotate through real consumer addresses — so use them as one signal, never as the only gate. Keep deny lists small, documented, and reviewed, because an over-broad CIDR can block a whole ISP’s viewers.

Request-method restriction

Restrict methods to what each route actually needs:

• Read-only content and media: GET and HEAD only.
• Form and API writes: the specific methods the endpoint implements.
• Reject TRACE and anything unexpected on public routes.
• Be deliberate about OPTIONS if you support CORS, and scope allowed origins tightly.

Method restriction is cheap, has almost no false positives when scoped per route, and closes a class of probing and abuse outright.

Default action versus exceptions

The single most important design choice is the default. Two viable models:

• Default allow, deny exceptions. Right for public content. You deny specific paths, methods, or sources. Low maintenance, but a missed exception is exposed.
• Default deny, allow exceptions. Right for sensitive surfaces — admin, preview, payout, internal APIs. You enumerate what is permitted. Higher maintenance, but a missed exception fails closed.

Apply default-deny to anything sensitive and default-allow to public media, and do not mix the two on one resource. Most access-control failures are a sensitive path accidentally sitting under a default-allow policy. Scope resources so the default matches the content.

Ordering and precedence

Rules evaluate in order and the first decisive match wins. Define precedence explicitly:

1. Allow rules for trusted internal and partner traffic, narrowly scoped.
2. Deny rules for admin/debug paths and known-bad sources.
3. Method restrictions.
4. Geo and referrer rules.
5. Default action for the resource.

Put an allow for a trusted caller before a broad deny, or the deny will catch it. Document the order — it is the part of policy that is easiest to get wrong and hardest to debug.

Logging access decisions

Log enough to explain every denial without logging sensitive data:

• The rule that matched, the decision, and the request’s coarse attributes (country, ASN, method, path pattern).
• Never log tokens, cookies, referrer strings containing session data, or any personal identifier. The sensitivity rules in Edge Workers runtime and storage apply here too.
• Distinguish policy denials from errors in the logs so you can tell a rule working from a rule misfiring.
• Retain long enough to investigate a complaint or tune a rule, and no longer than necessary.

Review denials regularly. A rule that blocks real viewers shows up as a spike in denials on a path that should be public.

Where AdultInfra fits

AdultInfra designs access policy with the right default per resource and logs decisions without capturing sensitive data. Age assurance, consent, licensing, and lawful-content obligations remain the customer’s responsibility; the edge enforces the boundary you define. Start with Edge Workers use cases for dynamic policy, or contact us to review a resource’s rules.