> For the complete documentation index, see [llms.txt](https://docs.bountysecurity.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bountysecurity.ai/creating-profiles/redirections.md).

# 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                                              | Never                                         |
| `2`         | On-site only                                       | On-site                                       |
| `3`         | In-scope only                                      | Rejected with an explicit compatibility error |
| `4`         | Always                                             | Always                                        |

`MaxRedir` limits additional redirect hops after the initial request. Zero means no redirects. Relative `Location` values resolve against the current request URL, preserving the scheme and explicit port. On-site means the same scheme, hostname and effective port; a hostname suffix is not sufficient. Pro also caps its single-step redirect loop at 30 hops.

Server follows 301, 302, 303, 307 and 308 responses according to the selected policy. It removes Cookie and Authorization headers when crossing origins, changes POST to GET for 301/302 and uses GET for 303 except HEAD. Pro's legacy single-step redirect path builds a fresh GET request, so method/header behavior is not identical. The local multi-step executor currently evaluates each immediate step response without following a redirect chain; use explicit steps when that response sequence matters.

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.