Response Header Whitelisting

Current Situation:
We have API using many different backend implementations and basically we never know which response headers are returned. We need to control what is returned to the API consumer. Currently we manage response headers within each proxy implementation using standard header manipulation techniques available.
This approach is cumbersome, difficult to maintain, and requires significant effort to manage changes.

Problem Statement:
We need a robust, maintainable, and proxy-independent solution for controlling and managing response headers returned by our APIs. Preferably something provided by APIGee out-of-the-box.
Our current search for out-of-the-box solutions within APIGee documentation has been unsuccessful.

Current Solution:
As an solution, we’ve implemented this in the post-proxy shared flow hook, utilizing a Key-Value Map (KVM) containing a whitelist of allowed response headers. A JavaScript iterates through the headers and removes any not present in the whitelist. This is working and fulfills our functional requirements. But it’s still something we needed to develop ourself.

Question:
Think this is a basic common requirement? Why does APIGee not provide this functionality?

How have other organizations addressed this?

Hi @FrankHinrichsen ,I noticed your question hasn’t been answered yet. Don’t worry—we’ll keep an eye on it and try to get some input from other members soon.

It seems like your solution is working.

There is no built-in “Header Allow listing” policy in Apigee, that allows you to explicitly stipulate a short list of the headers that can be included in a response. Maybe this is an interesting possible future enhancement? Adding a new policy to formalize and short-cut what you are doing. I don’t think it is a common requirement. I have been around Apigee for a long time, and I haven’t heard of people asking for a simpler way to do this.

There is a related option - if you have an Open API Spec for your APIs, you can apply the OASValidation policy to the response, to check for violations. This will flag any response that includes headers that are not in the spec. But this policy does not behave according to your described solution - removing headers that are not permitted. Instead this policy throws an error if it finds an invalid header. That might not be what you want.

2 Likes