Microservices have revolutionized the modern organization’s tech stack. Hyper-agile microservices now support faster development cycles, greater productivity, and uber-scalable systems. Lying in the shadow of this new era of architecture, however, is a cybersecurity vulnerability that costs its victims millions per year. API security is regularly overlooked until it’s too late.
APIs Keep the World Turning
The microservices economy can only function thanks to each software’s robust network of Application Programming Interfaces (APIs). An API facilitates the smooth transfer of data between different software, allowing separately-developed pieces of software to be assembled into a bespoke, cohesive tech stack. However, as microservices continue to reduce in size and increase in depth, the sheer quantity of APIs is scaling dramatically. Alongside this, the peripheral nature of APIs also mean that over-stretched cybersecurity resources will struggle to gain true visibility into the area. This shows a major mismatch between feature demands and security practices, as 97% of businesses recognize the essential importance of APIs in their digital transformation plans.
APIs have only become a major security concern within the last 5 years, and many companies continue to lag behind in their recognition of the dangers. Facebook learnt this the hard way: their largest ever data breach was a direct result of API misconfiguration. In 2018, it was discovered that the profile information and login credentials of up to 50 million accounts had been stolen. The theft was made possible by a vulnerability first introduced in 2017 via Facebook’s ‘View As’ feature. This allows for a user to view their own profile from the perspective of a friend’s account. However, the APIs surrounding the developer version of the mobile app allowed for major credential leakage. This API was responsible for generating an access token, which should neatly contain the permissions of the user. However, this bug meant the action generated an access token of the other Facebook account. Highly replicable, it became possible to bag the authentication tokens of almost every other Facebook user.
Discovered a full year after its introduction, this API vulnerability had greatly facilitated the theft and illicit takeover of other users’ accounts. The personally identifiable information (PII) scraped from these accounts – alongside the illicit access gained by cybercriminals – would have gone on to fuel lucrative and highly exploitative phishing campaigns.
How APIs Damage Cloud Security
For many organizations, Amazon Web Services (AWS) provides highly adaptive and scalable cloud data solutions. A vital foundation for many companies, its highly adaptable integration into different tech stacks has ushered in a new wave of major API weaknesses. One issue of particular note is the inclusion of hardcoded Amazon Web Services credentials within the API code itself. This creates a highly insecure environment, where AWS credentials can simply be extracted directly from the tech stack. Symantec researchers recently published new data on the astonishing scale of this security issue, looking at the nearly 2000 B2B apps that suffered from this weakness. Over three quarters of these apps contained the valid AWS logins for private cloud services; almost half included the valid login tokens for millions of Amazon S3-hosted private files.
One of the apps under scrutiny within the research paper was developed and marketed by a B2B company offering an intranet and communication platform. It also provided a mobile software-development kit (SDK), acting as infrastructure as a service (IaaS), and allowing customers to access the platform. However, this SDK included hardcoded copies of the B2B company’s cloud access keys. This in turn led to the exposure of every single customer’s private data hosted on the B2B company’s platform. Confidential company data, financial records, and employees’ PII were all included in this large scale weakness. Alongside complete exposure of their customer data, the company also found their own files totally
API authentication issues do not stop there: not only do hard-coded login tokens present an immense security risk, but the variety of API integration faults represent yet another cause for concern. Another common fault is within the authentication process itself. Many insecure APIs do not check the authentication token itself, but merely require the existence of one within the request. Representing a major risk, an attacker could send any non-null value as the auth token, and the API request will be successfully processed. Even when APIs are successfully written to securely authenticate, many fail to reinforce this with authorization. This facilitates the risk of privilege escalation. Suppose a user is logged in to their profile, which is reliant on a backend that fails to enforce authorization checks. The user account will be able to grab information over the same API by manually changing their user identifier. In this all-too-common API attack, authenticated attackers can exfiltrate highly confidential information, far beyond the expected threshold for that account.
Insecure APIs greatly amplify the security risk that businesses already face. Compromised accounts may have traditionally been limited by privilege-based restraints; now, however, cross-software integration allows attackers to breach deeper into your organization than ever before.
Securing the Cloud from API Mistakes
Perimeter-based security is outdated: inherent security must be a driving focus within every component of your tech stack. This requires a user-focused approach to API security, where the resources of each user are clearly defined. Every API must be built and tested iteratively; users must not be allowed access to functions external to their role.
API schemas can act like best-practice roadmaps, helping clarify which API calls are likely to be safe, and which need more attention. This process can also be reinforced with a visibility-first security solution provider. Scanning payloads and automatically assessing schema validation help you develop a more thorough overview. In turn, this helps prevent code injections, man in the middle attacks, and data leakage.