Add the ability to identify rewritten requests coming from Vercel

[SeinopSys]

Feature request

Is your feature request related to a problem? Please describe.

I need accurate visitor IP addresses for API rate limiting with a Laravel backend, and I want to avoid the barrage of OPTIONS requests that comes with having my API called directly via CORS on the client side. I still want my API to be accessible on its own domain for use in other applications. To this end, I set up my rewrites like so:

    async rewrites() {
      return [
        // we need to define a no-op rewrite to trigger checking
        // all pages/static files before we attempt proxying
        {
          source: '/:path*',
          destination: '/:path*',
        },
        {
          source: '/api/:path*',
          destination: `${process.env.BACKEND_HOST}/:path*`,
        },
      ];
    },

This is all well and good, and the redirects work perfectly, however, after looking at vercel/vercel#3012 and How do I identify my Vercel deployment IP address? it's clear that there is currently no way to verify that the contents of the X-Forwarded-For header are legitimate on the API server side.

Describe the solution you'd like

My suggestion would be to allow adding custom headers in the rewrites configuration, e.g.

    async rewrites() {
      return [
        // ...
        {
          source: '/api/:path*',
          destination: `${process.env.BACKEND_HOST}/:path*`,
          headers: {
            'x-vercel-secret': process.env.VERCEL_SECRET,
          }
        },
      ];
    },

This header then can be verified on the server side, and application logic can handle chopping off the last IP from the X-Forwarded-For header and treating the second to last value as authoritative, or do any further processing in case other proxies might be involved.

Describe alternatives you've considered

Another solution would be publishing IP ranges like Cloudflare does, but that's evidently out of the question:

Vercel deployments use dynamic IP addresses to ensure maximum scalability. As a result, it is not possible to determine the deployment IP address or address range because the IP may change at any time as the deployment scales instances or across regions.

Additional context

It's generally understood that the value of the X-Forwarded-For header should not be trusted blindly therefore some verification mechanism is necessary to enable this use case.

Since the IP address of Vercel deployments cannot be determined the API can't treat requests differently based on the connecting IP either, so in all cases it has to be accessible to the entire Internet even if that weren't originally intended.