In addition to names and contact details, the stolen information also included passport and Medicare data.
The company attributed the data breach to a sophisticated cyberattack, but further investigation reports revealed that Optus used an API that "did not require authorisation or authentication." In hindsight, anyone could have used that API endpoint to access those customer records.
Application programming interfaces (APIs) offer greater flexibility, cost-effectiveness, and rapid development options because they allow you and your users to reuse external software services and data flows. But if you aren't careful, those same API endpoints can also expose sensitive data and draw attacks from bad actors. Optus isn't unique in its failure to implement adequate API authentication, authorization, and encryption.
So, it's important that all your APIs are set up to prevent bad actors from accessing sensitive data. Otherwise, you risk data breaches, financial penalties, and user distrust.
API Security Protects Sensitive Data From Bad Actors
API security measures such as authentication, authorization, encryption, and monitoring can mitigate unauthorized access to a large extent.
Authentication is the process of questioning and validating the credibility of a user's identity. After user authentication, APIs also need to determine the level of resources every user is authorized to access. Use secret keys, protocols like OAuth 2.0, JSON web tokens (JWT), HTTP headers, or a combination of these methods to authenticate API users and validate their authorization levels.
For an additional layer of security, APIs can also use encryption, a process of converting plain data into an unreadable cipher that can be unlocked only with a valid key. However, even after implementing API security measures, the possibility of an attack still exists. So, it is important to use an external monitoring system that allows you to detect any anomalies in API usage.
OWASP, a nonprofit foundation that works toward improving software security standards, released a list of the top 10 API security risks. The top two API security risks being:
- Broken Object Level Authorization — Failing to validate user inputs or permissions before granting access to an object
- Broken User Authentication — Vulnerabilities that allow attackers to impersonate legitimate users
API Security Significantly Differs From Application Security
Because APIs are built to connect different applications and systems, they are infinitely extendable. But this extendibility creates fuzzy boundaries and unknown access points. So, API security requires additional discovery, testing, monitoring, and active runtime protection capabilities beyond what a conventional web app may require.
In addition to having more access points, APIs are more flexible to changes. For instance, an API can have more than one version in production. An API creator can choose to make a new API version available to new subscribers, even as existing users continue using its older version. These multiple API versions can, at times, pose security problems that a conventional web application firewall (WAF) might not detect.
On a similar note, APIs can also adapt to different software environments. For example, an API that is written in PHP can deliver a JSON or XML payload that can be used by an application that is written in JavaScript. Again, this adaptability can pose new cybersecurity threats that don't exist in web applications.
So, in order to bolster API security, you need to:
- Discover all your APIs: Tools such as Google Discovery or Postman automate the discovery of all your API endpoints. This is the first step toward identifying API security risks and gaps.
- Assess your existing level of API protection: Determine how secure your existing API gateway is and understand if you need to augment your WAF with Web App and API Protection (WAAP).
- Employ an API monitoring system: Detect behavioral anomalies and understand what's causing those pesky 4XX problems using tools such as Prometheus or Graphite.
- Perform API security tests: Uncover hidden security risks by testing your business logic and current API usage practices.
8 API Security Best PracticesÂ
Bad actors employ various brute force, credential stuffing, and distributed denial-of-service (DDOS) attacks to access API keys and sensitive data. So, you need to employ a combination of the following eight API security best practices.
1. Authenticate Users
Use the OAuth protocol to standardize the authentication of API users and sessions. By asking for user credentials in only one place, OAuth avoids exposing user credentials to bad actors. And it also helps you set customized API resource access rules.
You can also choose to use OpenID Connect on top of the OAuth protocol for an added layer of authentication security. OpenID relieves you from the responsibility of managing end-user credentials. It offers granular ‌access control features and provides your end users with features such as encryption of identity data, discovery of OpenID Providers, and a predefined logout option. It also allows web, mobile, and JavaScript clients to ask or get information about authenticated users or sessions.
API developers can also consider using SAML to authenticate their end users from a secure identity provider they already use, offering single sign-on (SSO) options.
A combination of these best practices helps you validate user identity and sessions in order to prevent API identification and authentication failures. Together, these practices help you:
- Withstand credential stuffing attacks
- Discourage users from reusing weak passwordsÂ
- Avoid inadequate session timeout settings
2. Implement Authorization Checks
After authenticating your API users, you still need to determine access levels for each user. Your safest option is the principle of least privilege.
With this method, all your API users' access defaults to the least amount of resources and data they need to perform their role. For example, a user from customer support can use an API to access support tickets, but they shouldn't have access to users' personally identifiable information (PII). This allows you to reduce your attack surface and minimize security threats from excessive data exposure.
Bad actors can use inadequate authorization checks to send legitimate API calls that they shouldn't be able to perform. For instance, a user that only has permission to read records can also write new records using an API by changing the HTTP method from GET to PUT. Implementing the right level of authorization checks helps you avoid such Broken Function Level Authorization threats.
3. Encrypt API Requests and Responses
Encrypting all data transfers between the API server and the client helps you mitigate risks from snooping or man-in-the-middle attacks. Encrypt REST APIs that use HTTP with either a Transport Layer Security (TLS) or a Secure Sockets Layer (SSL) protocol.
Either of these two protocols can effectively encrypt data in motion. However, you'll still need either a WAF or WAAP to protect data at rest that sits behind an API.
4. Manage API Keys Effectively
API keys provide users with a secure way to access resources and data from the API server. The following steps will help you manage API keys and prevent threats from improper assets management.
- Generate unique and random keys that make it impossible for bad actors to guess any pattern
- Define granular resource access rights for each user's API key
- Store the API keys as hashed values and not as plain text
- Delete the API keys that have little or no API traffic
5. Use Rate Limiting and Throttling
OWASP highlights that it is quite common for APIs to allow requests without any limitations. Bad actors can exploit such APIs by automatically executing multiple concurrent API requests. The overwhelming number of requests can eventually lead to denial-of-service (DoS) or make the API unresponsive.Â
APIs need to implement rate limits and throttle resource requests that exceed a predefined quota. A good practice is to define limits for:
- Memory
- CPU
- Number of restarts
- How frequently a user can place requestsÂ
6. Validate All API Resource Requests
An API gateway can help you protect API resources from unauthorized requests and malicious code injections.
It achieves this by validating user identity and providing temporary time-bound tokens that can be used to access API resources. This means that an API gateway can help a user to perform actions on a web application using identity data from the user's smartphone without actually sharing any usernames or passwords.
At the same time, the API gateway can allow or prevent resource usage to users based on identity validity.
7. Monitor API Usage
Monitoring API activity can help you detect anomalies that might be attacks. Monitoring also gives you a set of clues that can be used to trace how bad actors got in.
Insufficient monitoring systems give bad actors the time they need to access API resources without getting detected. Imagine that a web application gets hit with a credential stuffing attack, and thousands of failed login alerts get triggered. Without a monitoring system, the application team won't be alerted to this threat unless one of them happens to look at the login logs.
8. Test for API Security Risks
Routine API security testing can help you eliminate security misconfigurations. It also better prepares you to face an API attack. And it helps you uncover hidden business logic flaws that may lead to compromised data.
Security teams can eliminate mass assignment threats by periodically testing for business logic weaknesses that bad actors can exploit.
Manual API Security Testing Methods
The OWASP API Security Top 10 list provides a good framework for your testing. Use a combination of the following manual security testing methods to detect vulnerabilities in your internal APIs.
Test Parameter Tampering
Hackers can tamper parameters that are sent through APIs and gain unauthorized access to sensitive information. For example, an attacker can modify hidden form fields of an ecommerce website and actually buy products for a lower price.
To avoid such unauthorized actions, test your business logic, user workflows, and the accidental presence of hidden field information.
Test Command Injection
Bad actors can execute unauthorized operating system-level commands by injecting malicious code via forms, cookies, HTTP headers, URL changes, and SQL injections. For example, an attacker can create a wrapper around the UNIX command and inject it via an HTTP header.
Test if your API allows the injection of an operating system command, like system reboot. And take the necessary actions to secure your API from such command injections.Â
Test HTTP Methods
Bad actors can use various HTTP methods to store, delete, or retrieve data without adequate permissions. So, APIs that support HTTP methods on the server side are vulnerable to such attacks. For example, a bad actor can modify a GET method to a PUT or POST method.
To avoid this, test your API server to see if it allows the modification of HTTP methods. If it does, secure it.
Use Secure, Encrypted and Compliant External APIs
Australian Home Affairs Minister Clare O'Neil went on air and blamed Optus, saying they "effectively left the window open for data of this nature to be stolen." But companies like Optus aren't the only vulnerable ones. API vulnerabilities cost businesses $75 billion annually. Furthermore, ineffective API management can earn bad press, reputational harm, and the distrust of your users — causing irreversible damage.
Avoid these risks by only using external APIs that offer adequate security and encryption capabilities. Also, only select APIs that meet your business needs, such as GDPR or HIPAA compliance. So, for instance, if you're looking to use either a chat API or activity feed API, then among other considerations such as features, pricing, and support offered, you also need to factor in security and compliance.