A whitelisting approach for cloud APIs

Picture of a cloud with GOV.UK Notify and GOV.UK Pay written inside. There are 4 entry points to the cloud with one of them blocked with a cross.One common and powerful security measure you can apply to a system is controlling which other networks and computers it can talk to.

If you can detect your system is attempting to talk to unknown servers, then you get warnings of a compromise, and if you can prevent your system from accessing unknown servers, you can make it significantly more difficult for attackers to exploit any weakness.

The traditional approach to this has been IP address-based firewall rules, however this doesn’t work with modern cloud-based APIs.

Why we don’t support IP address whitelists for our APIs

We're often asked by government departments for the IP addresses of our APIs so they can be whitelisted in their network firewalls.

We don’t support the use of IP address whitelists for our API’s because these measures are not compatible with modern cloud architectures.

Cloud hosted APIs, like ours, take advantage of Content Delivery Networks (CDNs), and scalable load balancers, which rely on flexible, rapid allocation of IP addresses. They also often rely on sharing of IP addresses, making IP based restrictions ineffective.

A workable whitelisting approach

Happily there is a whitelisting approach that does work for cloud hosted APIs and provides equivalent benefits to IP whitelisting, and that’s using an HTTPS egress proxy.

In this approach, you have egress proxy software that sits at the edge of your network between your internal servers and the internet, and examines the HTTPS traffic from your internal servers to determine if it's intended for a trusted recipient based on the domain name. You configure the software to only allow traffic to an API endpoint, such as It can enforce that the server providing the API presents a valid TLS certificate for, ensuring the internal system is connecting to a trusted API via a secure connection.

Using an intercepting HTTPS proxy

The approach described above is the equivalent of traditional IP address based whitelisting. It’s also possible to configure egress proxy software so that it intercepts the HTTPS connection to inspect the contents of the data leaving the network (rather than just the traffic’s destination). There are trade-offs to this that you should consider.

The benefits of interception are that you can:

  • log more details of what is leaving the network
  • use data loss prevention technology to prevent sensitive data leaving the network.

The downside is the proxy is a more valuable target for attackers as any sensitive data is available at the proxy, which may include personal details or authentication tokens for external APIs.

Whether you do simple whitelisting or apply interception will depend on:

  • the type of APIs you're using
  • whether your API data is likely to be a target for attackers
  • how widely shared your proxies are
  • The capabilities you have to analyse logs generated by the proxies.

We use egress proxies without interception to connect GOV.UK Pay and GOV.UK Notify to supplier APIs. This has been relatively cheap and easy to deploy, as we've based them on the robust Squid proxy.

We’d be interested in your thoughts on whitelisting approaches. Please feel free to comment below.

You can follow David on Twitter, sign up now for email updates from this blog or subscribe to the feed.

If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.

Sharing and comments

Share this page