APIs (Application Programming Interfaces) play a crucial role in enabling communication between different software systems and building a secure web application is big part of that communication. However, this increased connectivity also brings about new security challenges. To protect your systems and data from potential threats, it’s essential to implement a comprehensive API security checklist. Below we’ll go over a few important security checks we all need to do for our organization security of information. And afterwards I’ll give you a crucial checklist of those generally important key points.
Authentication and Authorization
Authentication is the process of verifying the identity of a user or system interacting with the API. It ensures that only authorized entities can access the API. Use strong authentication mechanisms such as OAuth 2.0 or API keys.
Authorization defines what actions a user or system can perform after being authenticated. Implement granular access controls to limit access to specific resources based on the user’s role or privileges.
Data Encryption
Encrypt data both at rest and in transit to protect it from unauthorized access. Use strong encryption algorithms such as AES (Advanced Encryption Standard) for data at rest and TLS (Transport Layer Security) for data in transit.
Input Validation
Validate all input received by the API to prevent injection attacks such as SQL injection and cross-site scripting (XSS). Use parameterized queries for database access and sanitize user input to remove any potentially harmful content.
Rate Limiting and Throttling
Implement rate limiting and throttling mechanisms to prevent abuse and ensure fair usage of your API. Set limits on the number of requests a user or IP address can make within a certain time period.
Error Handling
Proper error handling is crucial for security as it can prevent information leakage. Return generic error messages to users and log detailed error information internally for debugging purposes.
Logging and Monitoring
Implement logging and monitoring to track API usage and detect any unusual or suspicious activity. Monitor access logs, error logs, and performance metrics to identify and respond to security incidents promptly.
Secure Communication
Ensure that all communications between clients and the API are encrypted using TLS. Disable support for outdated or insecure versions of TLS and use strong cipher suites.
API Gateway
Consider using an API gateway to centralize API management and apply security policies such as authentication, rate limiting, and logging. An API gateway can also help mitigate distributed denial-of-service (DDoS) attacks.
Regular Security Audits
Perform regular security audits and vulnerability assessments of your API to identify and remediate any security weaknesses. Conduct penetration testing to simulate real-world attacks and assess your API’s resilience.
Keep APIs Updated
Regularly update your APIs and dependencies to patch any known vulnerabilities. Stay informed about security advisories and best practices in API security to ensure your APIs remain secure against evolving threats.
API Security Checklist
Below is a very important checklist you need to keep, save and go over with your peers and engineers and colleagues and V&P and all other stack-holders to make sure all standards are held and information of your company is safe and secure.
Category | Item to Check | Why? | Did We Check? |
---|---|---|---|
Authentication | encryption is a must on all sensitive data | Encrypting sensitive data ensures that even if it is intercepted, it cannot be read without the decryption key. | |
Using Max Retry and jail access limitation features in Login and other sensitive area | To prevent brute-force attacks, limiting the number of login attempts and implementing account lockout mechanisms is crucial. | ||
Beware of reinvent the wheel in Authentication, token generation, password storage. Use the standards. | Reinventing authentication processes can lead to security vulnerabilities. Using established standards ensures best practices and security. | ||
Don’t use simple authentication. Use industry standard authentication instead (like JWT or 3rd party tools and companies). | Basic Auth sends credentials in plain text, which can be intercepted. Standard authentication methods like JWT are more secure and widely used. | ||
JWT | Use a random (as possible) complicated key (JWT Secret) to make brute forcing the token very hard. | Using a strong, random key for JWT encryption makes it significantly more difficult for attackers to decrypt the tokens. | |
token expiration (TTL, RTTL) as short as possible for your consumers. | Short expiration times minimize the risk of tokens being misused if intercepted. | ||
algorithm should be kept secret. don’t extract the algorithm from the header. Force the algorithm in the backend (HS256 or RS256). | Allowing the algorithm to be extracted from the header can lead to security vulnerabilities. Specifying the algorithm in the backend adds an extra layer of security. | ||
Avoid store sensitive data in the JWT payload, it can be decoded by attacker. | Storing sensitive data in the JWT payload makes it accessible to anyone with the token, even if they are not authorized to access the data. | ||
Avoid storing too much data. JWT is usually shared in headers and they have a size limit. | Excessive data in the JWT payload can lead to performance issues and potential security risks. | ||
Access | Access limit of requests (aka Throttling) helps avoid DDoS / brute-force attacks. | Throttling limits the number of requests an individual client can make within a given time frame, protecting the server from overload and attacks. | |
Use HTTPS on the server side with TLS 1.2+ and secure ciphers to avoid MITM. | HTTPS encrypts data transmitted between the client and server, preventing eavesdropping and man-in-the-middle attacks. | ||
Turn off directory listings, due to sensitive files and structure of internal system that can be expose. | Directory listings can expose sensitive information about your server’s directory structure and files. | ||
Use HSTS header with SSL to avoid SSL Strip attacks. | HSTS ensures that web browsers communicate with the server over HTTPS, even if the initial request was made over HTTP. | ||
For private APIs, allow access only from safelisted IPs/hosts. | Limiting access to known and trusted IPs/hosts reduces the risk of unauthorized access to the API. | ||
Authorization | validation of redirect_uri in the server-side to allow only safelisted URLs. | Validating redirect_uris prevents attackers from redirecting users to malicious sites after authorization. | |
Block access to development, stagging environment to external access. | Those environment may contain sensitive data or security holes. or company internal tools with high privilege access. | ||
OAuth | Use state parameter with a random hash to prevent CSRF on the OAuth authorization process. | The state parameter helps prevent CSRF attacks by ensuring that the request originated from the same user who initiated the OAuth flow. | |
Always try to exchange for code and not tokens (don’t allow response_type=token). | Exchanging for a code reduces the risk of token leakage and provides better security. | ||
Define the default scope, and validate scope parameters for each application. | Defining and validating scopes ensures that applications only have access to the resources they need, reducing the risk of over-privileged access. | ||
Input | Validate content-type on request Accept header. | Validating the content-type header prevents processing data in an unexpected format, which could lead to security vulnerabilities. | |
Use the proper HTTP method according to the operation. | Using the correct HTTP method ensures that the request is processed correctly and securely. | ||
Validate content-type of posted data as you accept. | Ensuring that the posted data matches the expected content-type prevents processing errors and potential security issues. | ||
Validate user input to avoid common vulnerabilities. | Input validation prevents malicious data from causing security vulnerabilities such as SQL injection or XSS attacks. | ||
Use only backend encryption. | Encrypting data on the server-side ensures that sensitive information is protected during transmission and storage. | ||
Don’t use any sensitive data in the URL, but use standard Authorization header. | Including sensitive data in the URL exposes it to potential interception and logging. Using the Authorization header keeps sensitive data secure. | ||
Use an single source of API Gateway service to enable caching, Rate Limit policies, and deploy APIs resources dynamically. | API Gateways provide additional security features like caching and rate limiting, improving overall API security. | ||
Processing | Check if all the endpoints are protected with authentication. | Ensuring all endpoints require authentication prevents unauthorized access to sensitive data and functionality. | |
avoid exposing internal data, User own resource ID should be avoided. Use /me/orders instead of /user/654321/orders. | Using a generic identifier like “/me” reduces the risk of exposing sensitive user information through URLs. | ||
Don’t auto-increment IDs. Use UUID instead. | Using UUIDs for IDs makes it harder for attackers to guess or enumerate valid IDs, improving security. | ||
If you are parsing XML data, make sure entity parsing is not enabled to avoid XXE. | XXE attacks can exploit entity parsing in XML to access unauthorized data. Disabling entity parsing prevents this vulnerability. | ||
If you are parsing XML, YAML or any other language with anchors and refs, make sure entity expansion is not enabled. | Entity expansion attacks can exploit anchor and ref features to cause denial of service. Disabling these features prevents such attacks. | ||
Work with CDN for file uploads. | Using a CDN for file uploads can improve performance and reduce the risk of server overload from large uploads and ddos attack. | ||
If you are dealing with a huge amount of data, use Workers and Queues to process as much as possible in the background. | Processing large amounts of data in the background reduces the risk of HTTP blocking and improves API responsiveness. | ||
Always turn the DEBUG mode OFF. | Disabling debug mode prevents sensitive information from being exposed in error messages, reducing the risk of security breaches. Debug mode expose sensitive information. | ||
Output | Submit X-Content-Type-Options: nosniff header. | Prevents browsers from MIME-sniffing a response away from the declared content-type, reducing the risk of XSS attacks. | |
Submit Content-Security-Policy: default-src ‘none’ header. | It helps prevent various types of attacks, such as Cross-Site Scripting (XSS), Clickjacking, and Data Injection attacks. | ||
Remove finger-printing or well known headers – X-Powered-By, Server, X-AspNet-Version, etc. | It prevent important information from attacker like which system you use and this way attack can’t tell what known security holes you have in your system. | ||
Send X-Frame-Options: deny header. | it helps prevent Clickjacking attacks. Clickjacking is a type of attack where an attacker tricks a user into clicking on a malicious link by hiding it beneath a legitimate-looking button or other clickable element on a web page. | ||
Avoid returning sensitive data like passwords, credentials, or security tokens | You should know why. | ||
Return the accepted status code according to the operation completed. (examples: 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, etc.). | strict code and communication between 2 companies reduces security vulnerabilities. | ||
Enforce content-type for your response.In case of application/json, then your content-type response is application/json. | It is considered a security best practice to always specify the Content-Type header to avoid any ambiguity in how the response should be processed by the client. | ||
Monitoring | Usage of agents is important to monitor all traffic, errors, requests, and responses. | tacking information assist thought forensic of cyber security vulnerabilities. | |
Use alerting systems. | SMS, Slack, Cloudwatch, Telegram, Kibana, email, etc, those help inform about problems faster and solve those problems faster. | ||
Use special IDS numbers and/or IPS system to monitor your http API requests and instances. | This way you’ll know what the full path of a request, where it start where it ends what happen in between etc. | ||
Don’t LOG PII, sensitive information | Logs of private information like password, PIN, card numbers, id numbers etc is at high risk with monitoring systems. | ||
CI & CD | Audit your design and implementation with unit/integration tests coverage. | with relevant stack holders like professional security engineers. | |
From time to time check your dependencies, 3rd parties, external tools, external services (both software and OS) for known vulnerabilities. | other tools and 3rd party packages and code may contain problems and vulnerabilities, recent example is linux backdoor security problem 2024 of supply chain attack. | ||
All code should be review, Pull requetes, and scanned by 3rd party services. | other engineers reading newly added code prevents security vulnerabilities. | ||
From time to time run security tests (dynamic/static analysis) on your code, can use 3rd party tools or services. | good examples of static and dynamic security analysis is jfrog, snyk code. | ||
have a rollback solution for deployments in advance | in crucial times it’s needed to rollback changes to avoid a long term damage to existing systems. |
Above list is a list I keep and I update on my notes from time to time and I often visit this list to see whether what I do as an engineer and cyber security expert meeting the start I expect to meet.
I am a software engineer with 20 years of experience of writing code, Software languages, Large scale web application, security and data protection of online digital assets in various software systems and services. I’ve decided to write and share my interests in cyber security online and information security to help and improve white hat security, safety and privacy of our online digital assets, As companies, as individuals or experts providing services. In here you’ll be able to read freely about cyber security threats, detections, common problems, services, news and everything related to information security and cyber security – enjoy and feel free to contact me via the contact page for any question.