Some notes/context:

• The headers restbase has been globally setting https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/restbase/+/refs/heads/master/lib/security_response_header_filter.js#70
• The headers rest-gateway is setting with the exception of content-security policy: https://gerrit.wikimedia.org/r/plugins/gitiles/operations/deployment-charts/+/refs/heads/master/charts/api-gateway/templates/_rest_routes.tpl
• How the rest-gateway sets the content-security-policy (Note: this function does not set deprecated CSP headers as restbase currently does. It also does not check for or impose the mobile policy, it is the app's responsibility to do this. If content-security-policy is set, we don't set it at the gateway level): https://gerrit.wikimedia.org/r/plugins/gitiles/operations/deployment-charts/+/refs/heads/master/charts/api-gateway/templates/_rest_csp_header.lua.tpl

Thanks for these notes @hnowlan. Very useful and I also saw this in the doc. Once I'm done with the research, I'll comment here with all the global headers we want rest-gateway to set then we can know the next step forward.

• The headers restbase has been globally setting https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/restbase/+/refs/heads/master/lib/security_response_header_filter.js#70
• How the rest-gateway sets the content-security-policy (Note: this function does not set deprecated CSP headers as restbase currently does. It also does not check for or impose the mobile policy, it is the app's responsibility to do this. If content-security-policy is set, we don't set it at the gateway level): https://gerrit.wikimedia.org/r/plugins/gitiles/operations/deployment-charts/+/refs/heads/master/charts/api-gateway/templates/_rest_csp_header.lua.tpl

@hnowlan, per the 2 links above, I've also double checked that the global response headers sent by RB matches what is returned by rest-gateway. That's a very good start, now I have to dig into each service to see if there are more common headers among services that are the same to make them global.

@hnowlan, everything in app.js for all services is already in rest-gateway global headers and it matches what was already in RB global headers.

We can do 1 of 2 things:

1. Leave global headers in rest-gateway and in app.js for all services for parity. So that if a service doesn't set it, then the gateway should and if the service has set it already, then the gateway can just forward.

2. We can remove the headers from app.js and rely only on rest-gateway to set the global headers common across services. This will mean remove code from app.js related to these global headers for all services.

But I would suggest we go with option 1 until we've finished migrating routing all traffic to go through rest-gateway and give some time for services to run before we completely rely on it for the global headers. So that in case a service needs a global header that the rest-gateway is not setting, then the service will set it and the gateway will forward it to clients.

In essence, what I mean here is, very little work is needed as rest-gateway global headers reflect RB global headers (requirements fulfilled). Maybe @pmiazga has extra thoughts here from the architecture side of things.

I think #2 is a worthy goal but not necessarily something we need to push for right now. Are there additional headers required or missing from the gateway at present?

In T336836#8926858, @hnowlan wrote:

I think #2 is a worthy goal but not necessarily something we need to push for right now. Are there additional headers required or missing from the gateway at present?

Okay Hugh, noted. Right now, I don't see any headers we are missing.

As API Gateway is nowadays owned by serviceops, adding the serviceops project tag to open API Gateway tasks tagged with the deprecated/archived "Platform Team Initiatives (API Gateway)" tag at https://phabricator.wikimedia.org/project/profile/4321/, as part of Phabricator Housekeeping.