How to Grow API Security, PCI Compliance with Swagger Specification

The Amazon API Gateway can be used to publicly publish an organization’s APIs. In just a few clicks or a few lines of code, one can set up an API Gateway proxying all requests from the Internet to a private application (usually custom code running in a private subnet). However, as the API Gateway becomes a public entry point into an AWS environment, it is necessary to secure it so that it blocks potentially malicious requests before reaching code.


As a result, it is important to reduce risks this entry point causes — such as a data breach — by reducing the exposure of code. Specifically, in today’s blog, we’ll explore how to increase security and PCI compliance by reducing the attack surface of APIs with the Swagger Specification.

While the AWS API Gateway is listed as a service in the scope of the AWS PCI compliance program, it does not mean one should keep Amazon’s default PCI implementation settings. PCI DSS v3.2.1 has the following requirement “1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.” The same requirement applies to HIPAA and many other compliance regulations. To protect the cardholder and their Personally Identifiable Information (PII), it is the responsibility of the business to configure the proper controls to block malicious requests.

Fig Source: https://aws.amazon.com/api-gateway/

Note that cloud-based projects share responsibility for cloud security. AWS refers to this as a “Shared Responsibility Model” and it’s important to understand where the responsibility of the public cloud provider ends and where yours begins. For example, AWS operates, manages and controls the components from the host OS and virtualization layer down to the physical security of the facilities where it operates. Customers are responsible for the management of guest OSs, application software, AWS WAF and more.

Addressing the Attack Surface

It is a basic security control to only allow the network traffic required for an application to be functional. Hackers should not be allowed to retrieve data from endpoints that are not intentionally part of the application. Security teams commonly refer to this as reducing the attack surface. Compliance is often an output of good security, and by addressing the attack surface, enterprises are able to help achieve regulatory compliance while protecting themselves from unwanted attacks. One significant way one can reduce security risk is by properly configuring elements within the IT infrastructure. Let’s continue on to take a look at how one can achieve this goal with API Gateways.

The API Gateway

As applications are developed, APIs are constantly added, removed and/or modified. Configuring the API Gateway as a proxy is an easy way to make APIs functional as nothing is restricted, and no configuration changes are required when an API is modified. And, developers do not need to inform the operations team about code changes. Developers could manually configure the API Gateway Request Validation, but it would require changes every time an API is updated, making the processing time consuming and error-prone.

Introducing Swagger

A well-known tool for developers, Swagger allows you to write API specifications as code. It uses the OpenAPI specification managed by the Linux Foundation; the specification simplifies API development while simultaneously making it easier for internal and 3rd party applications to consume APIs.

Swagger helps the API producer and the API consumer establish an understanding of the expected API request format. For example, you can define:

• Which endpoints should be available to users eg: mywebsite.com/products
• What HTTP methods can be used eg GET, POST, PUT
• What parameters can be passed, and what data can be returned

An API Gateway can be configured with a Swagger specification so that it takes charge of the Request Validation before the private application must.

To streamline the process even further, Flux7 has developed a generic API module using AWS CloudFormation to deploy the components required for the API Gateway and Swagger integration. Developers maintain the Swagger specification for each application, store it in Git and the specification is used to automatically configure the API Gateway, which minimizes the efforts required of the operations team. To achieve this process, Flux7 DevOps consultants have developed a Python script that automatically converts Swagger specifications to API Gateway compatible specifications. Some of the challenges listed here were also solved by the Python script.

Below is an example developer flow diagram for making API changes in Swagger. When the developer is ready to make changes to the API Gateway specifications, they use a pull request through an API-gateway pipeline.

The Amazon API Gateway is a very popular AWS service as it benefits IT operations, security and development teams. It allows developers to easily manage and publish multiple API versions while it provides Operations teams with the ability to rely on a scalable AWS-managed service that has built-in Amazon CloudWatch monitoring. And, it allows security teams to help ensure authorization and access controls are properly configured, addressing internal and external security requirements. When paired together, the Amazon API Gateway and Swagger can further improve the efficiency and efficacy of an enterprise’s security and compliance efforts, while streamlining development.

Interested in how Security by Design efforts such as this can help improve the security and compliance of your enterprise without slowing down development efforts? Reach out today: