title: How to verify if a request comes from the same project in App Engine? (mixed Flexible and Standard)
body: <p>First, a little context on our setup:</p>
  
  <p>In our setup, we have a Google App Engine project with a reverse proxy in the <code>default</code> service. It acts as an API gateway to all other microservices in the same project. This was recommended to us by Google engineers.</p>
  
  <p>All requests from clients to these microservices should be routed through this gateway, so we need the underlying services to respect the <code>X-Forwarded-*</code> headers when building new URLs. This causes a security problem though: a malicious user could forge the headers to make our application call endpoints in their own domain.</p>
  
  <p>To protect against this, the underlying services must be isolated from the external world. They must only accept requests that come from the same project (which is, the gateway and other microservices).</p>
  
  <p>In App Engine Standard there's a way to <a href="https://cloud.google.com/appengine/docs/standard/python/appidentity/#asserting_identity_to_other_app_engine_apps" rel="nofollow noreferrer">tell App Engine to include a <code>X-Appengine-Inbound-Appid</code> header</a> that validates the project, but we couldn't find anything similar to this in App Engine Flexible. In particular, <a href="https://cloud.google.com/appengine/docs/flexible/python/migrating#app_identity" rel="nofollow noreferrer">the migration guide says nothing about asserting request identity</a>.</p>
  
  <p><strong>How do we assert that a request came from the same App Engine project?</strong></p>
  
  <p>Is this possible at all in the flexible environment? We'd like to avoid implementing a shared secret (that could leak), or a mechanism where the services have to always check with the gateway if the request came from them :/</p>
  
  <p>Right now we're having to validate in the services themselves that the <code>X-Forwarded-*</code> headers adhere to its expected format, which beats the whole purpose of using the headers in the first place.</p>