Request/response modification as a rule action

Hi,

Today: rule actions are terminal only — block. The verdict never reaches our application.

Problem: our backend doesn't know what the platform thinks of a request, so it can't respond proportionally. We end up keeping rules in log-only mode wherever a hard block would be too blunt for the actual risk.

Request: a non-terminal "modify" action that can

• add, set, rewrite or remove request and response headers, and manipulate cookies
• where feasible, modify the response body (script injection, value substitution)
• inject platform-computed values: verdict, matched rule ID, JA4, country, ASN, request ID

Use cases: X-Bot-Score / X-Bot-Verdict driving graduated responses in business logic (hide contacts, trim results, lower limits, require verification, flag in anti-fraud); an end-to-end request ID for correlating platform events with application logs; centralised security headers without an app release; safe rollout — pass the verdict first, enable blocking once we trust the signal.

Benefit: lower cost of false positives, graduated enforcement instead of binary block/allow, one control point for headers.

Thank you for your feedback. We would first like to share one update: the Monitor mode for Allow & Deny → Custom Rules is already on our roadmap. In this mode, matched requests are logged without being blocked, allowing you to validate rule effectiveness and reduce the risk of false positives.

We have also recorded your request to combine this with Monitor mode by first passing the risk verdict to the origin for validation, and then progressively enabling blocking. We will track this request through our internal feedback process.

The specific design and timeline are still under internal evaluation. We will keep you updated as soon as there is any progress.

Ok, thank you
I also mean modify request/response header and body: masking or remove some data or header, redirect to specific page

At this stage, our priority is to support passing SafeLine’s detection results through to the upstream service or application in Monitor mode. The specific implementation approach and fields to be passed through are still under evaluation. We want the application to be able to receive and validate SafeLine’s detection results first.

We also understand your ideas about having SafeLine modify request headers, response headers, the response body, or cookies while the request continues to the upstream service, including masking data, replacing content, and redirecting users to a specific page. We will further evaluate these ideas based on technical feasibility and product planning.