# API security

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/api-security

## Quick definition

An API is a messenger that lets two programs talk to each other. API security means making sure only the right programs and people can use that messenger, and that they cannot steal or damage the information being exchanged. It is like having a security guard check every message before it goes through.

## Simple meaning

Imagine you want to order food from a restaurant. You call the restaurant, tell the person on the phone what you want, and they pass your order to the kitchen. The phone line and the person taking your order act as an API between you and the kitchen. Now, what happens if someone else picks up the phone and pretends to be the restaurant? They might take your credit card number and order food for themselves. That is a security failure. API security is everything we do to make sure the phone line is secure and the person taking orders is really who they say they are. It is also about making sure you only order what you are allowed to order, and that the kitchen only sends back what you paid for. In technical terms, an API is a set of rules that lets one software application talk to another. For example, when you use a travel app to book a flight, the app sends a request to the airline's API to check prices and seats. API security protects that conversation. It uses authentication to verify the identity of the app or user, authorization to ensure they have permission to perform the action, encryption to keep the data private, and rate limiting to prevent someone from overwhelming the system with too many requests. Think of an API as a doorway into a building. Without security, anyone could walk in, take files, change records, or even lock the real employees out. API security is the lock on the door, the security camera, the ID badge check, and the guard who asks why you are there. Every time you see a website that shows live weather data or a payment form that processes your credit card, an API is working in the background. Keeping that API safe is the job of API security.

## Technical definition

API security encompasses the strategies, protocols, and tools used to protect APIs from unauthorized access, data breaches, and denial-of-service attacks. At its core, API security relies on several key mechanisms. Authentication verifies the identity of the client making the request. Common methods include API keys, OAuth 2.0 tokens, OpenID Connect, and JSON Web Tokens (JWT). An API key is a unique string that identifies the requesting application, but it is relatively weak because it does not bind to a specific user session. OAuth 2.0 is a more robust framework that issues access tokens after a user or application authenticates, allowing scoped permissions. Authorization then determines what resources the authenticated client can access. This is often enforced through role-based access control (RBAC) or attribute-based access control (ABAC). Encryption protects data in transit, typically using TLS (Transport Layer Security) which ensures that data passing between the client and the API server is encrypted and cannot be read by eavesdroppers. Input validation and sanitization prevent injection attacks such as SQL injection, XML injection, and command injection where an attacker sends malicious data to exploit backend systems. Rate limiting and throttling restrict the number of requests a client can make within a certain time window, preventing abuse and denial-of-service attacks. API gateways are often deployed as a central enforcement point. They handle authentication, rate limiting, logging, and sometimes request transformation before forwarding traffic to backend services. Tools like AWS API Gateway, Azure API Management, and Kong are commonly used. Web Application Firewalls (WAF) can inspect API traffic for known attack patterns. API security also involves proper logging and monitoring to detect anomalous behavior, such as repeated failed authentication attempts or unusual data access patterns. The Open Web Application Security Project (OWASP) provides a specific top-ten list for API security risks, including broken object level authorization, excessive data exposure, and mass assignment. In cloud environments, API security is integrated with identity and access management (IAM) services, such as AWS IAM roles and policies, Azure AD, and Cloudflare Access.

## Real-life example

Think of a library. The library has a front desk where you can ask for books, return books, or request information. The front desk is like an API. It is the interface between you (the user) and the library's collection (the backend system). Now, imagine the library has no security at the front desk. Anyone could walk in, grab a book from the shelf without checking it out, take a librarian's computer, or even change the library catalog. That is a disaster. So the library introduces a security system. First, you need a library card. That card is like an API key. It identifies you as a member. When you come to the front desk, you show your card. The librarian checks if your card is valid and not expired. That is authentication. Next, the librarian checks what you are allowed to do. Some books are restricted to adults. Some resources are for staff only. The librarian checks your membership level and says, you can check out these three books, but not that rare manuscript. That is authorization. If you want to use the library's online catalog from home, you enter your card number and a password. The data you send is encrypted, like putting your library card number in a sealed envelope, so nobody on the internet can read it. That is encryption. Suppose a group of students tries to check out 500 books in one day. The librarian would say, slow down, you can only take five books per visit. That is rate limiting. Finally, the library keeps a log of every book you checked out. If someone tries to check out books using a stolen card, the log shows unusual activity and the library can investigate. That is monitoring and logging. Every step in this library's front desk procedure maps directly to a part of API security: authentication, authorization, encryption, rate limiting, and monitoring. Without these, the library would be chaos. Without API security, software systems are vulnerable to data theft, unauthorized actions, and service disruption.

## Why it matters

API security matters because APIs are the backbone of modern software. Almost every application you use relies on APIs to function. When you log into a website with your Google account, a Google API is authenticating you. When you pay for something online, the payment gateway API processes your transaction. When you check the weather on your phone, a weather API provides the data. These APIs handle sensitive information: personal data, financial details, passwords, health records, and more. If an API is not secured, attackers can exploit it to steal that information. For example, an insecure API at a bank could allow a hacker to transfer money from any account. In 2021, a major social media platform suffered a breach because an API vulnerability allowed attackers to access user phone numbers and email addresses. That affected over 500 million users. API security is not just about preventing data theft. It is also about ensuring availability. A company that relies on APIs for its revenue, such as an e-commerce site, can lose millions of dollars if an attacker launches a denial-of-service attack against the API, taking the site offline. API security also helps maintain compliance with regulations like GDPR, HIPAA, and PCI-DSS. These laws require organizations to protect personal and financial data. An insecure API can lead to non-compliance, resulting in massive fines. For IT professionals, understanding API security is essential for designing secure systems. Whether you are a developer building an API, a cloud architect designing a microservices architecture, or a security analyst monitoring network traffic, you need to know how to protect APIs. In cloud environments like AWS and Azure, API security is a shared responsibility. The cloud provider secures the infrastructure, but the customer is responsible for configuring authentication, authorization, and encryption correctly. A misconfiguration, such as leaving an API endpoint publicly accessible without authentication, can lead to a breach. As organizations move to microservices and serverless architectures, the number of APIs increases dramatically, making API security even more critical.

## Why it matters in exams

API security appears in several major certification exams because it is a core concept in modern IT. For the AWS Certified Solutions Architect Associate (AWS-SAA), you need to understand how to secure APIs using AWS API Gateway, including using API keys, IAM permissions, Lambda authorizers, and Cognito user pools. Exam questions often ask which combination of services provides the most secure API access. For Microsoft Azure Administrator (AZ-104), API security is covered in the context of Azure API Management and Azure AD authentication. You should know how to configure OAuth 2.0, manage subscriptions, and set up policies for rate limiting and IP filtering. The CompTIA Security+ exam includes API security under the domain of secure application development and deployment. Questions may focus on risks like injection attacks, broken authentication, and how to mitigate them with input validation and proper session management. The CompTIA CySA+ exam goes deeper into detecting API attacks, interpreting logs from API gateways, and using tools to identify API abuse. For the ISC2 CISSP exam, API security is part of the software development security domain. You need to understand how to integrate security into the API development lifecycle, including threat modeling, secure coding practices, and testing for vulnerabilities. Microsoft 365 Certified: Administrator Expert (MS-102) covers API security in the context of Microsoft Graph API permissions and consent, which is essential for managing access to Microsoft 365 data. The SC-900 Microsoft Security, Compliance, and Identity Fundamentals exam introduces API security basics, focusing on authentication and authorization concepts like OAuth and permissions. In all these exams, you are expected to know common API vulnerabilities (from OWASP API Security Top 10), how to use tokens and keys, and the difference between authentication and authorization.

## How it appears in exam questions

Exam questions about API security come in several formats. Scenario based questions are very common. For example, you might read about a company that deployed a new API for customer data and is getting reports of data leaks. The question asks you to identify the most likely cause and the best solution. The answer might involve fixing broken object level authorization or enabling rate limiting. Configuration questions ask you to choose the correct settings. For instance, in an AWS exam, you might see a question about setting up an API Gateway method that requires IAM authentication. The options could include different authorizer types, and you need to select the one that uses IAM policies. Troubleshooting questions present a scenario where an API is not working as expected. For example, a developer reports that their API calls are being rejected with a 403 Forbidden error. You need to figure out whether the issue is with the API key, the IAM role, or the network security group. Architecture questions are common in cloud exams. You might be asked to design a secure API architecture for a microservices application. The correct answer might involve placing the API behind an API Gateway, using OAuth for authentication, and encrypting all traffic with TLS. In Security+ and CySA+, you may get questions that describe an attack pattern. For example, an attacker sends requests with modified IDs to access other users' data. You need to identify this as an insecure direct object reference (IDOR) attack and recommend input validation or randomized IDs. Another common pattern is identifying a broken authentication attack where an attacker uses stolen tokens. You would need to recommend short lived tokens and token revocation. In CISSP, you might see questions about the software development lifecycle, asking at which phase API security should be addressed. The correct answer is during design and requirements, not after deployment. Some questions present a comparison between authentication methods, such as API keys vs OAuth 2.0, and ask which is more secure for a given use case. The key is to understand that API keys are simpler but less secure, while OAuth provides granular access control and supports user delegation.

## Example scenario

A small business named CloudBooks offers an online accounting service. They have a mobile app and a web app, both of which communicate with a central backend through a REST API. The API allows users to create invoices, upload receipts, and view financial reports. One day, a developer named Sam notices that someone has been accessing invoices that do not belong to them. Sam investigates and finds that the API endpoint for fetching an invoice expects an invoice ID, but it does not check whether the logged in user actually owns that invoice. An attacker simply changed the ID number in the request URL and could see any invoice in the system. That is a broken object level authorization vulnerability. Sam implements a fix: every time the API receives a request to fetch an invoice, it first retrieves the user ID from the authentication token, then queries the database to verify that the invoice belongs to that user. If it does not, the API returns a 403 Forbidden error. Sam also adds logging so that any unauthorized access attempt is recorded. This is a classic example of why API security is critical. A small oversight in authorization can expose sensitive financial data of thousands of customers. The fix involved changing the backend logic, not the API contract itself, and it required understanding how authentication and authorization work together.

## Common mistakes

- **Mistake:** Thinking that using an API key alone is sufficient for security.
  - Why it is wrong: An API key identifies the application, not the user. If the key is shared, lost, or embedded in client-side code, anyone can use it. It also does not prevent a legitimate user from abusing access.
  - Fix: Use API keys only for basic identification and pair them with OAuth 2.0 tokens or IAM roles for user-specific authentication and authorization.
- **Mistake:** Relying only on input validation and ignoring authorization at the API level.
  - Why it is wrong: Input validation prevents malformed data but does not stop a valid authenticated user from accessing data they should not see. Authorization checks are needed for every object access.
  - Fix: Implement authorization checks in every API endpoint that returns or modifies data, verifying that the user has permission for that specific resource.
- **Mistake:** Disabling or ignoring rate limiting because it is not needed for a small user base.
  - Why it is wrong: Attacks can come from many compromised accounts at once. Even a small service can be overwhelmed by a distributed denial of service attack or a brute force attempt on passwords.
  - Fix: Always enable rate limiting, even for small deployments. Set reasonable limits per user, per IP, and per API key.
- **Mistake:** Assuming that HTTPS encryption alone makes an API secure.
  - Why it is wrong: HTTPS protects data in transit but does not protect against attacks at the application layer, such as injection, broken authentication, or authorization flaws.
  - Fix: Use HTTPS as a baseline, but also implement authentication, authorization, input validation, and logging.
- **Mistake:** Exposing internal IP addresses or system details in API error messages.
  - Why it is wrong: Detailed error messages help attackers understand the backend architecture, version numbers, or database structure, making it easier to craft targeted attacks.
  - Fix: Return generic error messages to the client and log detailed errors server-side for debugging.

## Exam trap

An exam question presents an API that uses token-based authentication and asks what additional security measure is needed. The option says 'implement API keys' and another says 'check permissions for each resource'. Many learners choose API keys because they think more authentication is better. Understand the difference between authentication (who you are) and authorization (what you can do). When a question mentions an API that already authenticates users with tokens, the next logical step is to verify that users have permission to access the specific resource they requested. This is authorization, not another authentication layer.

## Commonly confused with

- **API security vs Web application security:** Web application security focuses on securing the entire web application, including the frontend, backend, and database, often against attacks like XSS and CSRF. API security is specifically about securing the interface between programs, which may or may not be part of a web application. (Example: A web application security measure would be adding a CAPTCHA on a login form. An API security measure would be requiring a valid JWT token on every API call.)
- **API security vs Network security:** Network security protects the communication channels between systems using firewalls, VPNs, and intrusion detection. API security protects the application layer, focusing on the requests and responses themselves, regardless of the network. (Example: Network security blocks an IP address from reaching the server. API security ensures that even if the request reaches the server, the user cannot access another user's data.)
- **API security vs Authentication:** Authentication is just one part of API security. It verifies who is making the request. API security also includes authorization, encryption, rate limiting, input validation, and logging. Authentication alone does not make an API secure. (Example: A valid username and password (authentication) lets you into the system, but without authorization you might still be able to see everyone's files. API security includes both.)

## Step-by-step breakdown

1. **Client sends request** — A user or application sends an HTTP request to the API endpoint. This could be a GET request to fetch data or a POST request to submit data. The request includes headers, parameters, and sometimes a body.
2. **Transport encryption** — The request is sent over HTTPS, which encrypts the data using TLS. This prevents anyone intercepting the network traffic from reading the request content, including any credentials or sensitive data.
3. **Authentication check** — The API gateway or the application server checks the authentication credentials provided by the client. This could be an API key, a JWT, or an OAuth token. If the credentials are missing or invalid, the server returns a 401 Unauthorized error.
4. **Authorization verification** — After authentication, the server checks whether the authenticated client has permission to perform the requested action on the specific resource. For example, does this user have read access to invoice 1234? If not, the server returns a 403 Forbidden error.
5. **Input validation and sanitization** — The server validates the request data to ensure it matches the expected format. For example, if an ID field expects a number, the server checks that the input is numeric. Unsanitized data is cleaned to prevent injection attacks. Invalid input results in a 400 Bad Request error.
6. **Rate limiting and throttling** — The server checks how many requests the client has made recently. If the client exceeds the allowed rate, the server returns a 429 Too Many Requests error. This prevents abuse and ensures fair usage.
7. **Process request and return response** — If all checks pass, the server processes the request, performs the necessary business logic, and returns a response. The response is also encrypted over HTTPS. The server logs the request details for monitoring and auditing.

## Practical mini-lesson

API security is a layered practice. As an IT professional, your goal is not just to enable APIs but to protect them. Start by choosing the right authentication method for your use case. For public APIs that serve third-party developers, API keys are simple but must be kept secret. Never embed API keys in client-side JavaScript or mobile app code that can be decompiled. Instead, use OAuth 2.0 with the authorization code flow and PKCE for mobile and single-page applications. This ensures that the user authenticates directly with the authorization server, and the client only receives a temporary token. When designing authorization, never trust the client to tell you what it is allowed to do. Always enforce authorization on the server. For example, if an API endpoint returns a user profile, do not just accept a user ID from the request. Extract the authenticated user ID from the token and use that to query the database. This prevents IDOR attacks. Input validation is another layer. Use a whitelist approach: define exactly what values are allowed. If an API parameter expects a country code, only accept values from a predefined list. Do not rely on blacklisting malicious inputs, because attackers can always find a bypass. Rate limiting should be applied at multiple levels. Limit requests per user, per IP address, and per API key. Consider using different limits for different endpoints. A login endpoint should have a lower rate limit than a read-only endpoint to prevent brute force attacks. Logging and monitoring are crucial because they provide visibility. Log all authentication failures, authorization failures, and unusual request patterns. Use a centralized logging system and set up alerts for anomalies. In cloud environments like AWS, you can use CloudWatch and API Gateway logs. For Azure, use Azure Monitor and Application Insights. Regularly test your APIs for vulnerabilities. Use tools like Postman, OWASP ZAP, or Burp Suite to simulate attacks. Conduct penetration testing and code reviews. Remember that API security is not a one-time setup. As your API evolves, new endpoints and parameters can introduce new vulnerabilities. Make security review part of your development process. Finally, understand the shared responsibility model in the cloud. In AWS, API Gateway handles some security aspects like TLS termination and basic rate limiting, but you are responsible for configuring authentication, authorization, and input validation. A misconfigured API can expose your entire backend. Always follow the principle of least privilege: give each component only the permissions it needs to function.

## Memory tip

Remember the six layers of API security by the acronym AUTH RIL: Authentication, Authorization, Transport encryption, Rate limiting, Input validation, and Logging. AUTH RIL, like a secure door that checks who you are, what you can do, encrypts your movements, limits traffic, inspects packages, and records everything.

## FAQ

**What is the difference between an API key and a JWT token?**

An API key is a static string that identifies an application, not a user. A JWT token is a JSON-based token that contains user information and claims, and has an expiration time. JWTs are more secure for user-based authentication.

**Why is OAuth 2.0 considered more secure than basic authentication for APIs?**

Basic authentication sends the username and password with every request, which can be intercepted. OAuth 2.0 uses tokens that can be scoped to specific permissions and have a limited lifetime, reducing the risk if a token is stolen.

**What is a common API vulnerability that appears in certification exams?**

Insecure Direct Object Reference (IDOR) appears frequently. It occurs when an API uses user-supplied input to access objects directly without checking if the user is authorized to access that object.

**Should I always use an API gateway for security?**

Not always, but an API gateway centralizes authentication, rate limiting, and logging, which simplifies security management. For small projects, you might implement security directly in the application, but for production systems, an API gateway is recommended.

**How does rate limiting prevent denial of service?**

Rate limiting restricts the number of requests a client can make in a given time window. If an attacker tries to flood the API with requests, the rate limiter blocks excess requests, preventing the backend from being overwhelmed.

**What is the role of TLS in API security?**

TLS encrypts the data transmitted between the client and the API server. It protects against eavesdropping, tampering, and man-in-the-middle attacks. Without TLS, sensitive data like passwords and tokens can be intercepted.

**What is the OWASP API Security Top 10?**

It is a list published by OWASP that identifies the ten most critical API security risks, including broken object level authorization, excessive data exposure, and mass assignment. It serves as a guide for developers and security professionals.

## Summary

API security is the discipline of protecting the interfaces that allow software applications to communicate with each other. It is a critical area in modern IT because APIs are everywhere, from cloud services to mobile apps to microservices architectures. API security involves multiple layers: authentication to verify identity, authorization to enforce permissions, encryption to protect data in transit, input validation to prevent attacks, rate limiting to ensure availability, and logging to enable monitoring. Understanding these concepts is essential for IT certification exams like AWS-SAA, AZ-104, Security+, CySA+, CISSP, and many others. In exams, you will be asked to identify vulnerabilities like IDOR and broken authentication, choose the correct security configuration, and design secure architectures. Common mistakes include confusing authentication with authorization, relying too heavily on API keys, and neglecting rate limiting. Remember the acronym AUTH RIL to recall the six main layers: Authentication, Authorization, Transport encryption, Rate limiting, Input validation, and Logging. By mastering API security, you not only prepare for exams but also gain practical skills to build and maintain secure systems in any IT role.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/api-security