Heroku fails to pass along the x-rapidapi-proxy-secret header

[Ethan99]

I developed an API using FastAPI and deployed it on Heroku, and subsequently listed it on RapidAPI marketplace. RapidAPI includes a header named x-rapidapi-proxy-secret, which I rely on to ensure that my API is only accessible through RapidAPI and not directly.

Here’s the middleware I implemented to validate this header:

api = FastAPI()
proxy_secret = os.environ.get("SECRET_KEY", None)

@api.middleware("http")
async def validate_rapidapi_header(req: Request, next_call):
    if proxy_secret:
        req_headers = req.headers
        print(req_headers)
        if (
                "X-RapidAPI-Proxy-Secret" not in req_headers
                or req_headers["X-RapidAPI-Proxy-Secret"] != proxy_secret
        ):
            return PlainTextResponse(
                "Unauthorized direct access", status_code=403
            )

    result = await next_call(req)
    return result

The issue I’m facing is that when a request comes from RapidAPI, I see in the Heroku logs that the initial request carries the x-rapidapi-proxy-secret header. However, after Heroku processes a redirect, the subsequent request does not contain this header at all.

From my logs, the first request displays all the necessary headers from RapidAPI, including the secret, but the request following the redirect only shows basic information without any RapidAPI-specific headers.

This situation causes my API to reject the second request because the required header is absent. As a result, my API becomes unusable for RapidAPI clients.

Is there a way to configure Heroku to retain this header during redirects? Or should I approach header validation differently in my application code?

[Tom_Artist]

Indeed, this situation often arises during redirects. It is known that certain HTTP clients and proxies may strip custom headers to protect against security vulnerabilities. As a result, the x-rapidapi-proxy-secret header can be lost when Heroku handles the redirect. One approach is to utilize additional headers such as x-rapidapi-host or x-rapidapi-key that may still be present post-redirect. Alternatively, consider reconfiguring your FastAPI application to minimize or eliminate redirects altogether, ensuring that your endpoint URLs are in precise alignment with those expected by RapidAPI. While whitelisting RapidAPI’s IP ranges might work, it’s generally less dependable due to possible changes in their IP addresses.

[charlottew]

This is a common issue when using FastAPI behind proxies. Your app is probably doing an HTTP to HTTPS redirect, and redirects usually strip custom headers like x-rapidapi-proxy-secret. Check your Heroku config to make sure it’s handling HTTPS properly in FastAPI. Set the FORWARDED_ALLOW_IPS environment variable so it trusts the proxy headers. Also make sure your RapidAPI endpoint is using HTTPS to avoid redirects altogether. Since middleware runs before redirects, there’s definitely a redirect happening somewhere in your request flow.

[aroberts]

your fastAPI might be the one doing the redirect. heroku usually keeps the headers intact during redirects, so you should check if your app itself is causing internal redirects that lose those headers. log the redirect location to understand what’s going on.