Redirections

Choose which response to inspect and how far the scanner may follow redirects.

Redirect behavior affects both the request destination and which response supplies the evidence. Set a finite maximum and test the chain your detector expects.

In the editor

For an active profile, select the step and open Response → Redirections. Choose Never, On-site only, In-scope only or Always under Follow redirections, then set Max redirections. Click OK to save the profile.

These choices describe the local Pro policy. Review the compatibility table before using the generated file on Server.

Exported mapping and Server compatibility

RedirType	Pro editor	Server .bb conversion
0	Unselected/default value; not a named radio option	Never
1	Never	On-site
2	On-site only	On-site
3	In-scope only	On-site
4	Always	Always

MaxRedir supplies the maximum redirect count. This mapping is a known compatibility difference: exporting “Never” from Pro does not currently mean “never” to the Server converter. For checks where following a redirect changes validity or scope, test the exported profile in each engine. A zero maximum also matters to execution; do not rely on an unlabeled default as a universal policy.

Pro's In-scope choice refers to Burp scope. Standalone Server has no copy of Burp's scope database. MCP adds its own origin confinement, which can reject a redirect even when the profile requests Always. REST does not install that MCP guard.

Detection examples

For an open-redirect detector, inspecting the initial Location header may be more useful than following the redirect. For a login workflow, a later page may be the intended evidence. Match the response your profile actually evaluates, and verify whether cookies/authentication remain valid along the chain.

Count redirect hops as extra traffic. Use controls that distinguish an intentional application redirect from a payload-driven one.