You would be hard-pressed to find a modern website or application that does not use APIs. Short for Application Programming Interfaces, APIs define what type of requests can be made between online actors. They also determine how the calls are made, what conventions they follow, what formats need to be used, and much more. APIs are quite easy to reverse engineer. They are often well documented and accessible through public networks- making them enticing targets for hackers and other bad actors. In addition, APIs are extremely susceptible to denial of services (DDOS) attacks.
API security deals with privacy and access control as well as the detection of attacks and identification of vulnerabilities. As API infrastructure grows, the potential for gaps in security also increases. To avoid security breaches and ensure the safety of sensitive data, it is important to integrate API security into the development process. Here are some basic things you need to know before embarking on your API security journey.
Understand the Risks
APIs are designed to provide access to your data from an outside source, and as such are at risk of being hacked. Most APIs, unfortunately, have weak access control, and some are not protected at all. Many IT experts predict that API attacks will be the biggest cyber security concern in the near future. In some extreme cases, it is not only your data that is at risk; API breaches can also endanger your infrastructure. Bad actors can gain access to your network and escalate privileges to effectively become a superuser. With such power over your network, multi-level attacks can be leveraged to compromise your most sensitive data.
Whatever the severity- a data breach is a serious event that not only costs you revenue but can damage your brand and reputation. It seems that no one is immune to breaches. Many industry leaders have fallen victim to API attacks – Google, Instagram, T-Mobile, Uber, Verizon, Facebook, just to name a few.
Common Web API Attacks
APIs are vulnerable to most of the same attacks that have become commonplace since the early days of the internet. The most common are:
Injection
This is an attack where harmful commands or code is inserted (injected) into a program. It most commonly occurs in places where ordinary input is required- username and password fields are a good example. The most common injection attack is SQL injection, where an attacker breaks into an SQL database and gains control over it. Cross-site scripting, or XSS, is another type of injection attack that consists of exploiting vulnerabilities in order to insert malicious scripts into a web app or website. Injection attacks can be mitigated by limiting response data to avoid leaking sensitive data.
DDOS
DDoS, or distributed denial of service, is an attack that renders a website, network or system unavailable to users. This is done by flooding the system with an excessive amount of traffic that it was not designed to handle. APIs endpoints are prime targets for DDoS attacks. Rate and payload size limiting is a good defense against DDoS attacks.
Man-in-the-middle
MitM attacks are based on intercepting traffic between two systems that communicate with each other. The aim of this attack is to circumvent mutual authentication by closely impersonating each endpoint. If this is done well enough to satisfy the expectations of both actors, the attacker acts as an invisible proxy between them. API MitM attacks can be carried out between the API and its endpoint, as well as between the API and web app (client).
Credential Stuffing
Credential stuffing is a type of cyber-attack where stolen credentials (usually lists of usernames and passwords) are used to gain unauthorized access to accounts. This is most commonly done using large scale automated login requests. The same applies to API authentication endpoints.
Securing APIs – Best Practices
To maximize the security and safety of their APIs, organizations need to stick to well-established security controls and implement these basic security best practices.
Security First
All too often, API security is no more than an afterthought in the software development lifecycle. After code is committed, security is often looked at as someone else’s problem. This approach leads to vulnerable code, so it is important to prioritize security and build it into APIs as soon as you start developing them.
Keep your APIs Organized
If you do not put effort into keeping track of your APIs, vulnerabilities can go undetected. No matter if you have hundreds of publicly available APIs or just a handful, they need to be properly inventoried and managed in order to be secured. Frequent perimeter scans are recommended in order to discover and inventory APIs.
Strong Authentication and Authorization
Your API security is only as strong as your authentication and authorization solution. Public APIs are sitting ducks. Authentication breaches happen either when an authentication factor can be easily broken in to or when APIs do not enforce authentication. Security is often lax for private APIs. as they are intended for internal use only. APIs are entrance points to a company’s database, so access control is of paramount importance. OpenID Connect and OAuth2.0 are proven authentication and authorization tools that should be implemented if possible.
Least Privilege
The principle of least privilege dictates that users, programs, systems, processes, and devices should only be granted the minimal access needed to complete an action. This principle should be applied to APIs as well.
Use TLS Encryption
TLS or transport layer encryption is a protocol whose main aim is to provide data integrity and privacy between applications. Some companies choose not to encrypt API payloads that they do not deem sensitive, but sensitive data such as login and credit card information should always be TLS encrypted.
Remove Confidential Information
Information that you do not mean to be share should always be removed from APIs. When used as a developer tool, APIs often contain sensitive information like passwords, keys, and other credentials. All of this information needs to be removed before making the API publicly available. This step is sometimes overlooked, either because of time constraints or a lack of concentration. Scanning tools should regularly be used to minimize the risk of exposing information that needs to be kept secret.
Don’t Expose Too Much Data
A common mistake made in API architecture is exposing more data than is necessary. This often occurs when data filtering is done via the user interface instead of by using endpoints. APIs should only return the minimal amount of data needed to carry out their function.
Validate Input
All input data should be fully validated before passing from an API to an endpoint. Rate limiting is a great way to set a threshold above which requests will be rejected.
