Configuring Flow Rules

Once Web Protection is active for your web application, you can begin defining Flow Rules — the policies that decide how incoming traffic is inspected, challenged, transformed, or blocked before it reaches your origin server.

This guide is a complete reference covering every field, tab, and option in the Flow Rules editor.

---

Before You Begin

• You should have an active Web Protection instance in your GatewaySentry account. If you haven't set one up yet, see Adding Web Protection.
• You should have a clear idea of the traffic policy you want to apply (e.g., paths to protect or rate limits to enforce).

---

How Flow Rules Work

Every Web Protection instance has a Flow — an ordered list of rules that are evaluated top-to-bottom for every incoming request.

Each rule is built from three parts:

Part	Purpose
WHEN — Match conditions	Decides which requests this rule applies to
DO — Rule behavior	Defines what GatewaySentry does to matching requests
THEN — What happens next	Decides whether to keep evaluating other rules or stop

How rules combine: A Continue rule applies its config and then keeps evaluating later rules — configs stack on top of each other. A Stop rule applies its config and freezes evaluation. A Deny rule ignores config entirely and immediately returns a 403 Forbidden.

---

Step 1 — Open the Flow Editor

From your Web Protection instance overview, locate the Flow card. It shows a summary of your existing rules and how they're evaluated.

1. Click Edit flow → in the top-right corner of the Flow card.

The Flow editor will open, showing your existing rules in a list on the left and the rule editor panel on the right.

Tip: New instances start with one default rule that applies a passive challenge to all traffic (/*). You can edit this rule, add new rules, or remove it entirely.

To add a new rule, click + Add rule below the rule list. To edit an existing rule, click it.

---

Step 2 — WHEN: Define Match Conditions

The Match conditions panel decides which requests this rule applies to. You can combine any of the four conditions below — when multiple are set, all must match (logical AND). Any field left empty matches all values.

PATH

The URL path the request is targeting. Supports glob-style wildcards.

Pattern	Matches
/*	All paths
/admin/*	Anything under /admin/
/api/v1/users	That exact path only
/*.php	Any path ending in .php

METHODS

The HTTP methods this rule applies to. Click + Add to select one or more (e.g., GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD).

Use case: Apply stricter rules to state-changing methods (POST, PUT, DELETE) while leaving safe methods (GET, HEAD) less restricted.

IPS

A list of source IP addresses or CIDR ranges this rule applies to. Click + Add to enter values such as 203.0.113.42 or 198.51.100.0/24.

HEADER

Match on a specific HTTP request header. Click + Add and provide the header name and value to match against.

Note: If you leave all four conditions empty, the rule matches every request. This is normally only used for a final catch-all rule at the bottom of the flow.

---

Step 3 — DO: Configure Rule Behavior

The Rule behavior panel has two tabs: Behavior (security and traffic actions) and Response (how responses are shaped going back to the browser).

Behavior Tab

Challenge Mode

Sets the security posture for matching requests. Toggle on to enable, then choose a setting:

Setting	Description
OFF	No challenges are applied. Not recommended for any public-facing endpoint.
PASSIVE	Quietly challenge known bots while allowing legitimate traffic through unimpeded. Good default for most paths.
STRICT	Challenge any unknown device. Suitable for sensitive paths like login or admin areas.
JSC	Force every request to solve a JavaScript compute challenge (proof-of-work).
CAPTCHA	Force every request to solve an interactive CAPTCHA puzzle. Highest friction.

Recommended: Start with Passive for general traffic and use Strict or higher for sensitive paths.

Sentry

Configures bot defense strictness. This works alongside Challenge mode to add a layer of bot-detection scoring.

Setting	Description
OFF	Sentry disabled.
Lenient	Block only the most obvious bots. Lowest false-positive risk.
Standard	Permit most browsers through while blocking most bots. Good general-purpose setting.
Hardened	Block most bots and most automated browsers (e.g., headless Chrome).
Lockdown	Only permit verified humans through. Highest friction.

JSC Proof-of-Work

Requires the visitor's browser to solve a small computational puzzle before the request reaches your origin. Invisible to humans, expensive at scale for bots.

• Difficulty (s): How hard the puzzle is. Range 1–5. Recommended: 3. Higher values increase bot deterrence but also increase load time for legitimate visitors on slower devices.

Puzzle CAPTCHA

A human-solvable puzzle challenge shown when the rule decides a request needs interactive verification.

• Stages: How many puzzle stages must be solved. Higher = more friction for both humans and bots.
• Fails to advance: Difficulty scaling for incorrect answers. After this many failed attempts, the puzzle becomes harder.

Rate Limit

Caps the number of requests a single client can make to this endpoint within a time window.

• Requests per limit: The maximum number of requests allowed.
• When exceeded (choose one):

Action	Description
Challenge	Force the configured challenge (CAPTCHA, JSC, etc.) to reset the rate limit counter.
Block	Reject the request outright.
Delay	Hold the request in a queue until the rate falls back under the limit.
Log only	Allow the request through but record the violation in your logs. Useful for tuning before enforcement.

Tip: Start with Log only when introducing rate limits so you can observe real traffic patterns before enforcing.

Block List

Advanced blocking based on IP or User-Agent.

• IP/CIDR: A list of IP addresses or CIDR ranges to block (e.g., 192.0.2.10, 198.51.100.0/24).
• User agents: A list of User-Agent globs to block (e.g., *curl*, BadBot/*).
• On match (choose one):

Action	Description
Return 403	Immediately respond with 403 Forbidden.
Challenge	Force the configured challenge before allowing the request.
Tarpit	Deliberately slow the connection to waste the attacker's resources without giving them a clean rejection.
Log only	Allow the request but record the match.

Redirect

Send matching requests to a different URL.

• Redirect to: The full URL to redirect to (e.g., https://www.example.com/new-path).
• Status: The HTTP status code returned to the browser.

Code	Meaning
301	Permanent redirect. Browsers and search engines update bookmarks and indexes.
302	Temporary redirect. The original URL is expected to come back.
307	Temporary redirect, preserving the HTTP method (e.g., a POST stays a POST).
308	Permanent redirect, preserving the HTTP method.

Use case: Use 301 for permanent moves (old → new domain), 307/308 when you need to preserve POST bodies during the redirect.

---

Response Tab

The Response tab controls how responses are shaped on their way back from your origin to the visitor's browser.

Edge Cache

⚠️ WARNING: Enabling Edge Cache will cache all responses from the origin server, regardless of what the origin's own caching headers say. Be very careful not to apply Edge Cache to authenticated pages, API responses with user-specific data, or any dynamic content. Cached responses can be served to other users.

Cache responses at GatewaySentry's edge for faster delivery.

• Preset (cache duration): Choose one of:
• None
• 30 seconds
• 1 minute
• 5 minutes
• 1 hour
• 1 day
• 1 week
• Cache key (optional): A random string used as part of the cache identifier. Changing this string invalidates all previously cached responses for this rule — useful when you've pushed an update and need cached pages to refresh.

Response Headers

Override or remove headers in the response on its way back to the browser.

• Set: Add or overwrite a header (name + value).
• Remove: Strip a specific header from the response (e.g., Server, X-Powered-By).

Use case: Add security headers like X-Frame-Options or remove headers that leak server software details.

HSTS

Adds the Strict-Transport-Security header, telling browsers to only ever connect to your site over HTTPS.

• Include sub-domains (checkbox): Apply HSTS to every subdomain as well.
• Preload (checkbox): Mark the site as eligible for inclusion in browser HSTS preload lists.

⚠️ Important: Once a browser receives an HSTS header, it will refuse plain-HTTP connections to your site for the duration of the policy. Be especially cautious with Preload, which is very difficult to reverse.

CORS

Configure Cross-Origin Resource Sharing responses at the edge.

• Allowed origins: Comma-separated list of origins permitted to make cross-origin requests (e.g., https://app.example.com, https://admin.example.com).
• Allow credentials (checkbox): Allow cookies and credentials to be sent on cross-origin requests.
• Allow all origins (checkbox): Allow any origin (*). Cannot be combined with "Allow credentials" — browsers reject that combination for security reasons.

---

Step 4 — THEN: Decide What Happens Next

After a rule matches and its configuration is applied, GatewaySentry needs to know whether to keep evaluating later rules or stop here.

Option	Description
Continue	Apply this rule's config, then keep checking the rest of the rules in the flow. Configs from later matching rules stack on top of this one.
Stop	Apply this rule's config and end evaluation. No later rules will be checked.
Deny	Ignore the rule's config entirely and immediately return 403 Forbidden. Used to block matching requests outright.

How to think about it: Use Continue for broad rules near the top (e.g., "all traffic gets passive challenge"), then Stop for specific overrides ("but /admin gets stricter rules"). Use Deny as a hard block for known-bad traffic.

---

Step 5 — Save Your Rule

Once you've configured WHEN, DO, and THEN, click Save in the bottom-right corner of the editor.

If you have unsaved changes, you'll see an unsaved changes badge in the editor header. Click Discard to revert your changes if you want to start over.

Note: Rule changes take effect at the edge within a few moments of saving.

---

Managing Rules

From the rule list on the left side of the editor, you can:

• Reorder rules by dragging the handle on the left edge of each rule. Order matters — rules are evaluated top-to-bottom.
• Duplicate a rule using the duplicate icon (useful when creating variations).
• Delete a rule using the × icon.

---

Best Practices

• Order matters. Place specific rules (e.g., /admin/*) above broad rules (/*) so they match first.
• Start permissive, tighten gradually. Begin with passive challenges and Log only rate limits, watch the logs, then escalate.
• Test before enforcing. Use Log only options on Rate Limit and Block List to validate your rules against real traffic before turning on enforcement.
• End your flow with a catch-all. A final /* rule with sensible defaults ensures every request gets a baseline policy.
• Be extremely cautious with Edge Cache and HSTS Preload — both can cause hard-to-reverse problems if misconfigured.

---

Need Help?

If you run into unexpected behavior with your Flow Rules, or need help designing a policy for a specific use case, please reach out to GatewaySentry Support.