This week, we take a deep dive into the Tinder API gateway and how it solves security challenges. We also have an article from Approov on how to protect runtime secrets for mobile APIs, and an article on Open Banking API security best practices. Finally, we look at how software bill of materials (SBOMs) can aid API attacks.
Article: Deep dive into the Tinder API gateway
API gateways are a pillar of API security, especially in enforcing transport security and rate limiting. I was interested to read the unusual approach taken by Tinder (yes, that Tinder), who took the unusual step of building their own API gateway solution: Tinder API Gateway (TAG). Their main justification for this decision was the inability to scale their current environment of over 500 microservices and several different API gateways across application teams. This led to complexity (resulting in a scaling problem), maintenance challenges, and inconsistent enforcement of gateway policy.
The core design concept behind TAG was configuration-driven development, whereby development teams could define their routing requirements in TAG-specific notation and, upon deployment, were automatically configured by TAG. There were also several other important considerations, many relating to API security, such as:
- Request and response scanning
- Schema registry for auto-generation of API documentation
- Detecting vulnerabilities, like bot attacks, and real-time traffic detection
- API standardization and auditing process
- Consistent and uniform session management
The article makes very specific references to the security challenges that Tinder faces: they have users in over 190 countries and handle high volumes of API traffic, some genuine but significant volumes from bad actors, too. Using a central API gateway allows them to block malicious traffic at the first point of ingress rather than exposing internal services to such traffic.
The basic TAG architecture is shown below:
To understand some of the unique features of TAG, it is instructive to look at how it processes an inbound request:
- TAG performs a reverse geolocation IP lookup (RGIL) to determine the country code and then to perform rate limiting or request banning.
- TAG scans both the request and response to check the semantics, and then streams data internally to other services, such as bot detection.
- TAG manages sessions through global filters.
- TAG pre-filters the request to remove any unwanted or unexpected data from the request before it is processed by internal services.
- TAG post-filters the response using predefined filters to remove any extraneous or unexpected data, like filtering of error logs.
While not every organization faces the unique scale of security challenges like Tinder, this article gives a fascinating insight into solving this problem at scale. I’m certainly looking forward to their next blog.
Article: Runtime secrets protection for mobile APIs
We have previously covered API vulnerabilities in mobile applications where attackers were able to retrieve API keys or application secrets from a mobile application using simple reverse-engineering methods. This week we feature an in-depth guide from Approov on how to fully protect API keys and runtime secrets.
Many developers embed their API keys within the application binary without realizing how easily they can be extracted from it, either using binary static analysis or through extraction “on the wire” with a machine-in-the-middle attack (MitM).
The article provides a great write-up on how the Approov mobile protection can be used to protect the integrity of the mobile application (referred to as mobile app attestation) and to provide a secure delivery channel for secrets. An interesting read that highlights a challenge developers commonly encounter.
Article: Open Banking API security best practices
Next is an article from HelpNetSecurity on best practices for API security in Open Banking. While more than 90% of banks are now offering open banking services to drive innovation and personalized banking services, nearly one in two customers have security concerns about open banking.
The article makes the following recommendations, covered here in brief:
- Go beyond your traditional methods and best practices for APIs โ consider using self-learning AI, behavioral analysis, security analytics, automation…
- Embrace a secure-by-design philosophy โ assume the worst and design for that.
- Actively discover APIs and track your inventory โ you can’t secure what you can’t see.
- Adopt a risk-based approach to security โ understand what matters and protect that.
- Implement zero-trust policies.
- Identify and remediate vulnerabilities, gaps, and misconfiguration โ continuously reduce your attack surface.
- Stop API attacks in real time.
There aren’t any great surprises in this list for readers of this newsletter, but they are worth reinforcing, regardless of your industry sector.
Article: Can SBOMs help API attacks?
Finally, another great article from Dana Epp, this time covering the topic of software bill of materials (SBOMs) and whether they can aid API attackers.
SBOMs have become a hot topic in the software security industry following the Executive Order on Improving the Nationโs Cybersecurity that President Biden issued in May 2021. For readers unfamiliar with SBOMs, think of them as a list of ingredients for an application: typically they include the dependencies (libraries and components) that your application uses. Intuitively, having an up-to-date SBOM allows an organization to immediately assess the risk an application might pose based on the risk of the constituent components.
However, there is a downside to having an SBOM that may become available to adversaries: it is a simple matter to map an SBOM into a corresponding vulnerability database (describing the nature of the vulnerability) or โ even worse โ into a vulnerability exploit database (describing how attacks can be launched against know vulnerabilities). A skilled API attacker could map all vulnerabilities in a given API and then construct attacks that specifically target those vulnerabilities.
In my opinion, I would rather know about the vulnerabilities in my application and actively remediate them, rather than try to keep them hidden, in the vain hope that attackers do not find them.
Event: Defending APIs with Jim Manico
Episode 1: Request Forgery on the Web – CSRF & SSRF
In the first of two episodes, Jim Manico, CEO of Manicode, and Colin Domoney from 42Crunch discuss request forgery and how to prevent it. This technical talk is intended for software developers who needs to build secure web applications and APIs. It covers the two variants of request forgery: client side (CSRF) and server side (SSRF).
- CSRF is most widely associated with vulnerable web applications that trick a user in a client browser into submitting transactions they never intended to use in their current authenticated session. We discuss historical CSRF attacks and investigate various well-proven defense strategies. For API developers, we investigate whether APIs are vulnerable to CSRF, and how to prevent it.
- SSRF attacks allow a malicious client to trick a vulnerable server into submitting requests to an unintended location, typically by submitting malformed URLs in payloads and relying on vulnerabilities in the URL parsing code. We discuss prevention strategies and examine some well-known examples. For API developers, we investigate ways in which SSRF can be directed at vulnerable APIs and examine a few recent API breaches and the latest research.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
