Hardening E-Commerce APIs to Secure Billion-Dollar Retailers

At fabric we are building a modular and headless commerce platform with the vision of becoming for commerce services what AWS is for web services. And due to the headless nature of our platform, APIs run the show. So much so that a multi-billion dollar equipment supplier just signed a multi-million dollar contract with us to consume our commerce APIs.

API security was a concern before I joined fabric in January 2021, but as we attract more billion-dollar retailers such as Restoration Hardware, GNC, and Staples—including more general market interest with our recent $100M Series B—API security is now a high priority.

In this post, I will show you our general approach for securing APIs to support these major retailers. But first, let’s briefly review why API security matters.

Why Is API Security Important in Retail?

At fabric we use APIs to connect internal platform services such as cart, checkout, and pricing, and external services such as Stripe (payments), Alavara (tax), and Algolia (search). These connections mean data transfer and compromised APIs are behind major data breaches. With mainstream retail, personally identifiable and payment information is widely required to conduct trade and, as e-commerce grows, the attack surface grows with it.

The API Security project by OWASP supports this:

“A foundational element of innovation in today’s app-driven world is the API. From banks, retail and transportation to IoT, autonomous vehicles and smart cities, APIs can be found in customer-facing, partner-facing and internal applications. By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII) and because of this have increasingly become a target for attackers. Without secure APIs, rapid innovation would be impossible.”

Below I will describe the tactics we use to secure our APIs. With these tactics, the top ten API security threats identified by OWASP are directed. Note: The OWASP API Security project is nascent and needs contributors!

How We Secure APIs

These are the different RESTful APIs we use:

• Customer storefront APIs: Our Storefront API protects e-commerce store frontends (including mobile apps). It is a modular, customizable, and secure API gateway that provides a single data source for all your UIs.
• Third-party APIs: These are APIs provided by fabric to third-party vendors like Zendesk or RevCascade to access order and inventory modules. For example, mapping APIs are used to update inventory with new products from merchants.
• Merchant application APIs: This is a customer API that is unique for each customer.

All of our API traffic is securely transmitted using HTTPS and modern TLS protocols. In addition to applying security best practices for data in transit via APIs, we take these security measurements:

Internal vulnerability testing

Using vulnerability assessment tools (e.g. QRadar, Qualys, and Nessus) and considering new security enhancements throughout the software development life cycle (SDLC) is essential for keeping APIs secure. At fabric, our continuous vulnerability management process makes security a key aspect of API development.

Security tooling is part of our CI/CD pipeline and automated security-focused unit tests run against every deployment. Additionally, we run monthly vulnerability scans to identify and categorize API security issues for all of our customers. If we identify any critical security vulnerabilities, they’re patched within a week.

Third-party pen tests

Third-party penetration tests reputable firms (e.g. SpiderLabs, Cobalt, and FireEye) provide an objective expert analysis of a system’s security. A third-party pen test can expose vulnerabilities an internal audit and automated testing alone can miss.

In addition to leveraging automated scanning tools, third-party pen testers provide the human expertise necessary to identify misconfigurations and exploits that could otherwise go unnoticed.

For example, automated tooling is great at identifying common vulnerabilities and exposures (CVEs), but an attack that exploits business logic in an e-commerce site’s frontend APIs may go undetected. Simply put: third-party testing manipulates and attempts to hack an API in the same ways a real attacker would. This human perspective makes it possible to detect and correct misconfigurations and logic flaws before an attacker exploits them.

At fabric, we conduct third-party pen tests for our entire API annually and before every major release.

Authentication and authorization

Validating users are who they say they are (authentication) and only allowing access to resources they have permissions for (authorization) is fundamental to API security. fabric authenticates users and then provides them with a JSON Web Token (JWT) for subsequent requests. Authorization of those requests is secured using Okta’s implementation of the industry-standard OAuth 2.0 protocol.

End-to-end, the process works like this:

1. A client sends credentials (username and password) to the fabric login API.
2. The credentials are verified by comparing what the client provides to a salted hash. (Credentials are encrypted using a robust hashing algorithm.)
3. If the credentials are valid, the API signs and returns a JWT. If the credentials are invalid, the login request is rejected. Rate-limiting on the login API prevents brute force attacks.
4. The client verifies the token and sends the signed token with every subsequent request. This eliminates the need for the client to include credentials for any other requests in the session.
5. OAuth 2.0 authorization ensures that the client can only access API endpoints they have adequate permissions for.

API throttling

DDoS attacks can prevent an e-commerce site from processing legitimate orders and are one of the biggest threats facing large retailers. API throttling allows us to limit the number of API requests per second and prevent DDoS from bringing a site down.

Of course, with any throttling, there is the risk of false positives. To mitigate this risk, we use automation to optimize the throttling of APIs and reduce false positives while still providing protection from malicious attacks. Additionally, limits are based on both steady-state rates and bursts to account for different behavior patterns.

To implement API throttling, we use AWS API Gateway. At a high level, the throttling process works like this:

1. Clients call an API.
2. If the number of requests is less than the throttling limit, the request is processed normally.
3. If the number of requests exceeds the throttling limit, the user receives an error and must wait to send additional requests.

API keys

Like API throttling, API keys help limit abuse of our API and protect e-commerce sites that depend on it. API keys include a unique identifier (key ID) that allows us to meter access and prevent attacks.

Keys are created for each fabric customer and tied to specific entities. Clients must include a key ID and secret key in their requests. By tracking key IDs, we can hone in on malicious behavior and block it at the source.

VPCs, subnets, firewalls, and security groups

Virtual Private Clouds (VPCs), subnets, and AWS security groups allow us to implement granular access controls to restrict our API. Only API calls that are defined into a security group can access VPCs that contain instances. Security groups act as a virtual firewall for each instance to control inbound and outbound traffic.

Similarly, firewall rules allow us to implement granular access control lists (ACLs) and filter incoming traffic. For example, we restrict API calls to our internal API to only allow access from authorized customer domains. Requests from unauthorized domains are blocked even if the credentials are valid, allowing for defense-in-depth in the event credentials were compromised.

CORS support

By default, modern web clients only allow servers to execute scripts from their own origin (an origin is a domain, scheme, or port). This is known as the same-origin policy. From a security perspective, the same-origin policy has obvious benefits. For example, it prevents a malicious site from executing JavaScript that reads data from another webpage a user is logged into.

Of course, there are plenty of legitimate reasons a site or API may need to call resources with a different origin. Cross-Origin Resource Sharing (CORS) solves this problem and allows servers to securely access resources from specific, pre-defined domains.

To implement CORS, we use the AWS CloudFront CDN and AWS CORS for our REST APIs. Our implementation ensures only authorized cross-origin scripts can be executed.

Here’s a simple example of how we use CORS in practice:

1. A client uses the fabric Commerce API gateway to load their website from an S3 Bucket at example.website.s3.us-east-1.amazonaws.com.
2. To load resources and allow users to interact with the online store and shop, the site uses JavaScript to make authenticated HTTP GET and PUT requests against the same example.website.s3.us-east-1.amazonaws.com bucket.
3. Typically, a modern web browser would block the requests to example.website.s3.us-east-1.amazonaws.com because they’re from a different origin. However, with CORS, we can explicitly allow specific cross-origin requests (in this case, example.website.s3.us-east-1.amazonaws.com), and the site will work as intended.

Conclusion

What we’ve discussed here covers a majority of the API attack surface. Still, we also perform regular code security audits; maintain compliance with standards including PCI DSS, SOC2 Type II, NIST 800, and OWASP Top 10; and implement robust identity and access management to secure our APIs.

In addition to directing common API security issues, we document our security approach to help customers understand how their data and the data of their customers is protected when using our commerce platform.

If you’re developing an API-based platform for retailers (or for users within another industry), implementing the tactics described in this blog post will harden the platform instances you deploy for your customers. It will also secure shopping-related data at scale and help your customers earn trust among shoppers in this evolving digital landscape.

Niloufar Heidari

Information security engineer @ fabric. Previously cyber security @ SGCIB and KPMG.