The OWASP API Security Top 10 are mitigated in the development of web APIs.
Ensure APIs enforce strict object-level authorization to prevent unauthorized access to sensitive data. For example, implement server-side access control to verify user permissions before granting access to objects identified by user-supplied IDs; Prevent Insecure Direct Object References (IDOR) by ensuring object access is restricted based on ownership and authorization rules; Apply least privilege access to limit exposure of data beyond what is necessary for each user; Continuously audit API endpoints and enforce security policies to detect and remediate unauthorized data access vulnerabilities.
Ensure a robust authorization mechanism that enforces user policies and hierarchy to prevent unauthorized access. For example, implement role-based or attribute-based access control (RBAC/ABAC) to ensure users can only perform actions permitted by their roles; Enforce authorization checks in every function that processes client-supplied input to access database records, verifying that the logged-in user has the necessary permissions; Use random and unpredictable values (GUIDs) for record IDs to prevent enumeration attacks and unauthorized access attempts; Develop and maintain automated security tests to validate the authorization mechanism, ensuring no changes are deployed if they introduce vulnerabilities or cause test failures.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-15-01-01-01 | Implement proper authorization mechanisms | Development and implement an authorization mechanism based on user policies and hierarchy to ensure that only authorized users can access and perform actions on objects. | Development | Security Engineers, Backend Developers |
| SSS-02-15-01-01-02 | Check authorization in every data access function | Use the authorization mechanism to check if the logged-in user has permission to perform the requested action on a record. This should be done in every function that uses a client-supplied identifier to access a data source. | Development | Backend Developers, Security Engineers |
| SSS-02-15-01-01-03 | Use random and unpredictable values for object identifiers | Prefer using GUIDs or other random and unpredictable values for record IDs instead of sequential identifiers to prevent attackers from guessing object IDs and gaining unauthorized access. | Development | Backend Developers, Security Engineers |
| SSS-02-15-01-01-04 | Write tests for authorization mechanisms | Develop and execute tests to evaluate the effectiveness of the authorization mechanisms. Ensure these tests pass before deploying any changes that could compromise security. | Development | QA Teams, Security Engineers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1851) OWASP Top 10 API Security Risk OWASP Top 10 API Security Risk |
Ensure API authentication mechanisms are securely implemented to prevent unauthorized access and identity compromise. For example, enforce strong authentication using multi-factor authentication (MFA) and secure password policies to reduce the risk of credential theft; Protect authentication tokens by using short expiration times, secure storage, and proper revocation mechanisms to prevent token hijacking; Implement rate limiting and account lockouts to mitigate brute force and credential stuffing attacks; Use secure transport protocols (TLS 1.2+) to protect authentication data in transit; Continuously monitor authentication attempts and log anomalies to detect and respond to suspicious activity.
Ensure secure authentication practices by thoroughly understanding and implementing industry-standard mechanisms. For example, identify and document all authentication flows (mobile, web, deep links, etc.) to prevent overlooked vulnerabilities; Recognize that OAuth and API keys are not authentication mechanisms and ensure proper authentication protocols are in place; Avoid custom authentication implementations, relying instead on well-established standards for token generation and password storage; Apply strict security controls to credential recovery and password reset endpoints, treating them as login endpoints with brute force, rate limiting, and lockout protections; Require re-authentication for sensitive operations such as email or multi-factor authentication (MFA) changes to prevent unauthorized modifications; Follow the OWASP Authentication Cheatsheet for best practices; Enforce multi-factor authentication (MFA) where possible to strengthen user security; Implement anti-brute force mechanisms stricter than regular rate limits to mitigate credential stuffing and dictionary attacks; Apply account lockout and CAPTCHA mechanisms to prevent targeted brute force attacks and enforce weak-password checks; Ensure API keys are used solely for API client authentication, never for user authentication.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-15-02-01-01 | Identify all authentication flows | Ensure all possible authentication flows (e.g., mobile, web, deep links) are accounted for and understood by the development team. Ask engineers to review and identify any overlooked flows. | Preparation | Security Engineers, Development Teams |
| SSS-02-15-02-01-02 | Understand authentication mechanisms | Familiarize yourself with the authentication mechanisms used in the system. Ensure you understand the differences between authentication and authorization (e.g., OAuth, API keys) and how each is implemented. | Development | Security Engineers, Software Architects |
| SSS-02-15-02-01-03 | Use standard authentication methods | Do not reinvent the wheel for authentication. Use established standards for token generation and password storage (e.g., bcrypt, OAuth) to ensure secure implementations. | Development | Security Engineers, Software Developers |
| SSS-02-15-02-01-04 | Implement rate limiting and lockout on credential recovery | Treat credential recovery endpoints (e.g., forgot password) with the same security controls as login endpoints, including brute force protection, rate limiting, and account lockout mechanisms. | Development | Backend Developers, Security Engineers |
| SSS-02-15-02-01-05 | Require re-authentication for sensitive operations | Enforce re-authentication for sensitive actions, such as changing critical account details (e.g., email address, 2FA phone number), to ensure actions are legitimate. | Development | Backend Developers, Security Engineers |
| SSS-02-15-02-01-06 | Implement multi-factor authentication and anti-brute force mechanisms | Implement multi-factor authentication (MFA) where possible and apply anti-brute force mechanisms (e.g., stricter rate limiting, account lockouts, captchas) to prevent credential stuffing and brute force attacks. | Development | Security Engineers, DevOps Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1851) OWASP Top 10 API Security Risk OWASP Top 10 API Security Risk |
Ensure proper authorization validation at the object property level to prevent unauthorized data exposure or manipulation. For example, enforce attribute-based access control (ABAC) to restrict access to sensitive object properties based on user roles and permissions; Implement allowlists to explicitly define accessible fields in API responses, preventing excessive data exposure; Prevent mass assignment vulnerabilities by restricting direct updates to sensitive fields and using explicit mappings in API requests; Regularly audit API responses and input validation to detect and mitigate unauthorized property access or modification.
Ensure APIs expose only necessary object properties and prevent unauthorized data access or modification. For example, enforce strict access control to verify that users can only retrieve object properties they are authorized to see; Avoid using generic serialization methods (e.g., to_json() or to_string()) and instead explicitly define the specific object properties to be returned; Prevent mass assignment vulnerabilities by disallowing automatic binding of client-supplied input to internal objects or properties; Restrict modifications to only the object properties that clients are allowed to update, minimizing unintended changes; Implement a schema-based response validation mechanism to enforce strict data output rules, ensuring API methods return only the expected data; Keep response payloads minimal, returning only essential data required for business functionality, reducing exposure of unnecessary or sensitive information.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-15-03-01-01 | Ensure proper authorization for object properties | When exposing an object through an API, verify that the user has the correct permissions to access the specific properties of the object being returned. | Development | Security Engineers, Backend Developers |
| SSS-02-15-03-01-02 | Avoid generic methods for data exposure | Do not use generic methods like to_json() or to_string() to expose object data. Instead, selectively choose the properties to expose, limiting exposure to sensitive or unnecessary data. | Development | Backend Developers, Security Engineers |
| SSS-02-15-03-01-03 | Prevent mass assignment of client input | Avoid using functions that automatically bind client input to internal objects or object properties (e.g., Mass Assignment), which can lead to unauthorized changes. | Development | Security Engineers, Backend Developers |
| SSS-02-15-03-01-04 | Allow changes only to specific object properties | Ensure that clients can only modify the object properties that they are authorized to update. Do not allow arbitrary changes to sensitive or system-critical properties. | Development | Security Engineers, Backend Developers |
| SSS-02-15-03-01-05 | Implement schema-based response validation | Use schema-based validation to enforce strict controls over the data returned by API methods. This ensures that only expected and authorized data is returned to clients. | Development | Security Engineers, API Developers |
| SSS-02-15-03-01-06 | Minimize returned data according to business requirements | Limit the data returned in API responses to the absolute minimum necessary to meet the business and functional requirements of the endpoint, reducing the risk of excessive data exposure. | Development | API Developers, Security Engineers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1851) OWASP Top 10 API Security Risk OWASP Top 10 API Security Risk |
Ensure APIs enforce limits on resource consumption to prevent excessive usage leading to service disruption or increased operational costs. For example, implement rate limiting and throttling to restrict the number of requests per user or IP, preventing abuse and denial-of-service attacks; Apply quotas and cost controls for APIs that trigger expensive operations, such as sending SMS, emails, or biometric validations; Use circuit breakers and timeout mechanisms to prevent long-running requests from exhausting system resources; Continuously monitor API usage patterns to detect anomalies and mitigate potential exploitation of resource-intensive operations.
Ensure resource consumption is controlled and excessive usage is mitigated to prevent service disruption or increased operational costs. For example, use containerization or serverless solutions (e.g., AWS Lambda) to enforce automatic limits on memory, CPU, process counts, and restarts, preventing resource exhaustion; Define and enforce maximum data sizes for incoming requests, including string lengths, array sizes, and file upload limits, regardless of storage location; Implement rate limiting to control how often clients can interact with APIs within a specific timeframe, adjusting thresholds based on business needs; Restrict high-impact operations, such as OTP validation or password recovery requests, to prevent abuse by limiting retries; Apply strict server-side validation to control the number of records returned per request, preventing excessive data retrieval; Configure spending limits for API integrations and service providers, or set up billing alerts when usage monitoring is required instead.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-15-04-01-01 | Limit resource consumption using containers/serverless | Use technologies like containers or serverless code (e.g., Lambdas) to limit resource consumption such as CPU, memory, and storage. These solutions can help enforce resource limits on the backend. | Development | DevOps Teams, IT Operations |
| SSS-02-15-04-01-02 | Define maximum size for incoming data | Set limits on the size of incoming data, such as maximum string lengths, the number of elements in arrays, and the maximum file upload size. This prevents excessive resource usage by large payloads. | Development | Security Engineers, Backend Developers |
| SSS-02-15-04-01-03 | Implement rate limiting | Apply rate limiting to control how frequently clients can make requests to the API. This protects the system from high resource usage and abuse while maintaining normal service levels. | Development | Security Engineers, Backend Developers |
| SSS-02-15-04-01-04 | Fine-tune rate limiting based on business needs | Customize rate limiting for specific API endpoints based on the business needs. Some endpoints, such as critical authentication or payment services, may require stricter rate-limiting policies. | Development | Product Managers, Security Engineers |
| SSS-02-15-04-01-05 | Limit and throttle client operations | Implement limits and throttling on specific actions, such as limiting how often a client can request password recovery or validate an OTP, to avoid unnecessary resource consumption and prevent abuse. | Development | Backend Developers, Security Engineers |
| SSS-02-15-04-01-06 | Validate query parameters and request bodies | Ensure proper server-side validation for parameters in the query string and request body, especially parameters that affect the volume of data returned (e.g., pagination limits) to avoid excessive load on the server. | Development | Backend Developers, Security Engineers |
| SSS-02-15-04-01-07 | Configure spending limits and billing alerts | For third-party service providers or APIs (e.g., SMS, email services), configure spending limits and set up billing alerts to monitor costs and prevent unexpected charges due to excessive resource consumption. | Post-deployment | IT Operations, Financial Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1851) OWASP Top 10 API Security Risk OWASP Top 10 API Security Risk |
Ensure APIs enforce strict function-level authorization to prevent unauthorized access to privileged actions. For example, implement role-based access control (RBAC) or attribute-based access control (ABAC) to restrict access to administrative and sensitive functions based on user roles; Enforce server-side authorization checks for all API endpoints to prevent privilege escalation; Clearly separate regular user functions from administrative functions, ensuring that access to high-privilege actions requires explicit authorization; Regularly audit API permissions and access logs to detect and remediate unauthorized access attempts.
Ensure a centralized and consistent authorization module is enforced across all business functions to prevent unauthorized access. For example, implement default-deny access control, requiring explicit role-based grants for every function to prevent unintended privilege escalation; Regularly review API endpoints to detect function-level authorization flaws, ensuring alignment with business logic and user group hierarchies; Enforce strict inheritance for administrative controllers, requiring all admin functionalities to derive from an abstract controller that enforces role-based access control (RBAC); Ensure authorization checks are applied within regular controllers for administrative actions, validating user roles and permissions before execution; Continuously audit and refine access control policies to detect and mitigate potential misconfigurations.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-15-05-01-01 | Implement a consistent authorization module | Create a consistent, easy-to-analyze authorization module that is invoked by all business functions. This centralizes access control logic, reducing complexity and potential gaps in protection. | Development | Security Engineers, Software Developers |
| SSS-02-15-05-01-02 | Enforce default deny policy | Implement an enforcement mechanism that denies all access by default. Only explicitly grant access to specific roles for each function, ensuring strict control over who can access what. | Development | Security Engineers, Backend Developers |
| SSS-02-15-05-01-03 | Review api endpoints for function level authorization flaws | Regularly review API endpoints for function-level authorization flaws, considering the business logic and user groups/hierarchies. Ensure that sensitive functions are properly protected based on roles and permissions. | Development | Security Engineers, API Developers |
| SSS-02-15-05-01-04 | Use administrative controllers with role-based authorization | Ensure that all administrative functions inherit from an abstract administrative controller, which implements role-based authorization checks for the user's group/role. | Development | Backend Developers, Security Engineers |
| SSS-02-15-05-01-05 | Implement authorization checks in regular controllers for admin functions | Ensure that administrative functions in regular controllers also implement role-based authorization checks to prevent unauthorized users from accessing administrative functionality. | Development | Security Engineers, Backend Developers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1851) OWASP Top 10 API Security Risk OWASP Top 10 API Security Risk |
Ensure APIs implement safeguards against excessive or automated abuse of critical business functions to prevent financial loss or service disruption. For example, enforce rate limiting and throttling on sensitive transactions such as purchases, account registrations, or content submissions to prevent automated exploitation; Implement CAPTCHA, authentication, or step-up verification for high-impact actions to deter bot-driven abuse; Monitor API usage patterns and anomalies to detect and mitigate excessive or fraudulent interactions; Regularly assess business logic vulnerabilities to identify flows that could be exploited at scale.
Ensure mitigation strategies address both business risks and technical protections to prevent automated threats and excessive API usage. For example, identify business flows vulnerable to abuse, such as rapid purchases, automated registrations, or bulk data extraction, and implement appropriate security controls; Apply device fingerprinting to block unexpected client devices, making it costlier for attackers to bypass security; Use human detection methods, such as CAPTCHAs or biometric-based authentication, to differentiate between real users and bots; Detect non-human behavioral patterns by analyzing usage anomalies (e.g., completing multiple transactions in unrealistically short timeframes); Restrict access to developer and B2B APIs, which are often targeted due to weaker security implementations; Consider blocking traffic from Tor exit nodes and known proxy networks to prevent attackers from hiding their identities; Continuously refine security measures to balance usability with strong protections against automated threats.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-15-06-01-01 | Identify sensitive business flows | Identify the critical business flows (e.g., purchasing tickets, posting comments) that could negatively impact the business if excessively used, particularly in an automated manner. | Preparation | Product Managers, Business Analysts |
| SSS-02-15-06-01-02 | Implement business-level mitigations | Develop a mitigation plan at the business level, ensuring that high-risk business flows are carefully managed to prevent abuse or overuse. | Development | Security Engineers, Product Managers |
| SSS-02-15-06-01-03 | Apply protection mechanisms for automation mitigation | Implement protection mechanisms such as device fingerprinting, human detection (e.g., CAPTCHA or biometric solutions), and analysis of user behavior patterns to slow down automated threats. | Development | Security Engineers, Software Developers |
| SSS-02-15-06-01-04 | Analyze and block non-human patterns | Use behavioral analysis to detect non-human patterns, such as rapid interactions with "add to cart" and "complete purchase" functions. Implement throttling and blocking mechanisms when suspicious patterns are detected. | Development | Security Engineers, Backend Developers |
| SSS-02-15-06-01-05 | Secure b2b and machine-consumed apis | Restrict and secure access to APIs consumed by machines (e.g., B2B APIs) by enforcing stricter authentication, rate-limiting, and security measures to prevent automated abuse. | Deployment | API Developers, IT Operations |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1851) OWASP Top 10 API Security Risk OWASP Top 10 API Security Risk |
Ensure APIs validate and restrict outbound requests to prevent SSRF attacks that exploit user-supplied URIs. For example, enforce allowlists to limit external requests to trusted domains and block unauthorized internal network access; Validate and sanitize user-provided URLs to prevent manipulation of backend requests; Restrict server-to-server communications by applying network segmentation and firewall rules; Implement least privilege access for API requests to prevent unauthorized interactions with internal systems; Continuously monitor and log outgoing API requests to detect and respond to suspicious activity in real time.
Ensure secure resource fetching by isolating it within the network and applying strict validation controls. For example, restrict access to internal resources by ensuring resource-fetching mechanisms only retrieve authorized remote resources; Implement allowlists to define trusted remote origins (e.g., Google Drive, Gravatar), permitted URL schemes and ports, and acceptable media types for each functionality to prevent unauthorized access; Disable HTTP redirections to prevent attackers from redirecting requests to malicious destinations; Use secure and well-maintained URL parsers to avoid inconsistencies that could lead to security vulnerabilities; Enforce input validation and sanitization on all client-supplied data to prevent injection attacks; Avoid sending raw responses directly to clients, ensuring responses are properly processed and filtered before transmission.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-15-07-01-01 | Isolate resource fetching mechanism | Isolate the functionality responsible for fetching remote resources into a separate network segment. This minimizes the potential impact of SSRF attacks by restricting access to internal systems. | Development | Security Engineers, IT Operations |
| SSS-02-15-07-01-02 | Implement allow lists for remote origins and url schemes | Use allow lists to restrict the remote origins (e.g., Google Drive, Gravatar) from which resources can be fetched. Also, define allowable URL schemes (e.g., HTTP, HTTPS) and ports for safe requests. | Development | Security Engineers, Backend Developers |
| SSS-02-15-07-01-03 | Enforce accepted media types | Define and enforce accepted media types for each functionality to ensure that only legitimate and expected content is processed. | Development | Security Engineers, Backend Developers |
| SSS-02-15-07-01-04 | Disable http redirections | Disable HTTP redirection functionality to prevent attackers from redirecting requests to internal services or unintended destinations. | Development | Security Engineers, Web Developers |
| SSS-02-15-07-01-05 | Use a well-structured url parser | Implement a well-tested and maintained URL parser to avoid parsing inconsistencies that can lead to SSRF vulnerabilities. | Development | Backend Developers, Security Engineers |
| SSS-02-15-07-01-06 | Validate and sanitize client-supplied input | Validate and sanitize all client-supplied input data, including URLs, to ensure they do not contain malicious content that could exploit SSRF vulnerabilities. | Development | Security Engineers, Backend Developers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1851) OWASP Top 10 API Security Risk OWASP Top 10 API Security Risk |
Ensure API configurations follow security best practices to prevent misconfigurations that expose systems to attacks. For example, enforce secure defaults by disabling unnecessary features, endpoints, and permissions to reduce the attack surface; Restrict API keys, credentials, and sensitive configurations from being exposed in public repositories or logs; Enable security headers and encryption protocols to protect API communications; Regularly audit API configurations, access controls, and cloud settings to identify and remediate security gaps; Continuously monitor API deployments to detect unauthorized changes or misconfigured security settings.
Ensure a secure API lifecycle by implementing a consistent hardening process, configuration reviews, and automated security assessments. For example, establish a repeatable API hardening process that enables fast and secure deployments with locked-down environments; Regularly review and update configurations across orchestration files, API components, and cloud services (e.g., S3 bucket permissions) to minimize security risks; Automate continuous security assessments to detect misconfigurations and enforce security best practices in all environments. Additionally, enforce secure API communication by requiring TLS encryption for all internal and external API interactions; Restrict HTTP methods by explicitly defining allowed verbs and disabling unnecessary ones (e.g., HEAD); Secure browser-exposed APIs by implementing CORS policies and security headers to prevent cross-origin attacks; Limit accepted data formats to only those required for business functions to reduce attack surfaces; Ensure consistent request handling across all HTTP servers (e.g., load balancers, proxies, back-end servers) to prevent desynchronization attacks; Define strict response payload schemas, including error handling, to prevent sensitive system details from being exposed to attackers.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-15-08-01-01 | Implement a repeatable hardening process | Establish a repeatable hardening process that ensures fast and secure deployment of a locked-down environment for the API. This should be part of the standard deployment lifecycle. | Development | DevOps Teams, Security Engineers |
| SSS-02-15-08-01-02 | Review and update configurations | Regularly review and update configurations across the entire API stack, including orchestration files, API components, and cloud services (e.g., S3 bucket permissions) to ensure they follow security best practices. | Development | Security Engineers, DevOps Teams |
| SSS-02-15-08-01-03 | Automate continuous configuration assessment | Implement an automated process to continuously assess the effectiveness of configurations and security settings in all environments, ensuring they remain secure over time. | Post-deployment | Security Engineers, IT Operations |
| SSS-02-15-08-01-04 | Encrypt all api communications | Ensure that all API communications, both internal and public-facing, are transmitted over an encrypted communication channel (e.g., TLS) to protect against data interception and tampering. | Development | Security Engineers, DevOps Teams |
| SSS-02-15-08-01-05 | Restrict http verbs and disable unnecessary ones | Be specific about which HTTP verbs are allowed for API access. Disable any unnecessary HTTP verbs (e.g., HEAD) to reduce the attack surface. | Development | Security Engineers, Backend Developers |
| SSS-02-15-08-01-06 | Implement cors and security headers | For APIs expected to be accessed from browser-based clients, implement a proper Cross-Origin Resource Sharing (CORS) policy and include applicable security headers to protect from common web vulnerabilities. | Development | Web Developers, Security Engineers |
| SSS-02-15-08-01-07 | Restrict incoming content types | Restrict the accepted content types and data formats to only those that are necessary for the business or functional requirements, preventing unexpected or malicious data from being processed. | Development | Backend Developers, Security Engineers |
| SSS-02-15-08-01-08 | Enforce uniform request processing across servers | Ensure that all servers in the HTTP server chain (e.g., load balancers, proxies, backend servers) process incoming requests uniformly to prevent desynchronization issues. | Deployment | IT Operations, DevOps Teams |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1851) OWASP Top 10 API Security Risk OWASP Top 10 API Security Risk |
Ensure all API endpoints, versions, and hosts are properly documented and managed to prevent security risks from outdated or exposed services. For example, maintain an up-to-date API inventory to track all deployed endpoints, versions, and dependencies, reducing the risk of forgotten or vulnerable APIs; Enforce lifecycle management by deprecating and securely removing outdated API versions to prevent attackers from exploiting legacy functionality; Restrict access to debug and test endpoints, ensuring they are not exposed in production environments; Continuously monitor API deployments to detect shadow APIs and unauthorized endpoints that could introduce security risks.
Ensure comprehensive API security by maintaining a structured inventory, enforcing access controls, and applying security measures across all API environments. For example, document and track all API hosts by categorizing them based on environment (e.g., production, staging, test, development) and defining network access permissions (e.g., public, internal, partners) to prevent unauthorized access; Inventory all integrated services, documenting their role, data flows, and sensitivity to understand security risks; Maintain detailed API documentation covering authentication, error handling, rate limiting, CORS policies, and endpoint specifications, ensuring clarity for authorized users; Automate API documentation generation using open standards and integrate it into the CI/CD pipeline, restricting access to only authorized users; Protect all API versions—not just production—by using API security solutions to prevent unauthorized access or data leaks; Avoid using production data in non-production environments, or if necessary, apply the same security controls as production systems; When updating APIs with security improvements, assess risks in older versions and determine whether backporting is viable or if deprecating outdated versions is necessary to enforce secure adoption.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-15-09-01-01 | Inventory all api hosts | Maintain a comprehensive inventory of all API hosts, documenting key details such as the environment (e.g., production, staging, test, development), network access levels (public, internal, partners), and API version. | Development | Security Engineers, DevOps Teams |
| SSS-02-15-09-01-02 | Inventory integrated services | Document all integrated services, detailing their roles in the system, the data they exchange, and the sensitivity of that data. This helps in managing access control and monitoring potential vulnerabilities. | Development | Security Engineers, IT Operations |
| SSS-02-15-09-01-03 | Document all aspects of the api | Ensure that every aspect of the API is documented, including authentication mechanisms, error handling, redirects, rate limiting, CORS policies, and endpoint details (parameters, requests, responses). | Development | API Developers, Product Managers |
| SSS-02-15-09-01-04 | Automate api documentation generation | Adopt open standards for API documentation and integrate the documentation generation into the CI/CD pipeline to ensure it is always up to date and accessible. | Development | DevOps Teams, API Developers |
| SSS-02-15-09-01-05 | Restrict api documentation access | Make API documentation available only to authorized users, ensuring that sensitive information is not exposed to unauthorized parties. | Post-deployment | Security Engineers, IT Operations |
| SSS-02-15-09-01-06 | Implement api protection measures for all versions | Use external protection measures (e.g., API security solutions) for all exposed API versions, not just for the current production version. This ensures that older and deprecated versions are also protected. | Development | Security Engineers, IT Operations |
| SSS-02-15-09-01-07 | Avoid using production data in non-production environments | Prevent the use of production data in non-production environments to mitigate the risk of data exposure. If using production data is unavoidable, ensure the security of non-production endpoints is equivalent to that of production. | Development | Security Engineers, QA Teams |
| SSS-02-15-09-01-08 | Perform risk analysis for api version updates | When introducing security improvements in newer API versions, conduct a risk analysis to determine whether backporting is feasible or if older versions should be deprecated and all clients moved to the latest version. | Development | Security Engineers, Product Managers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1851) OWASP Top 10 API Security Risk OWASP Top 10 API Security Risk |
Ensure APIs securely handle data received from third-party integrations to prevent indirect attacks. For example, treat third-party API responses as untrusted input by validating and sanitizing data before processing it; Enforce strict authentication and authorization for external API integrations to prevent unauthorized access; Implement rate limiting and monitoring on third-party API calls to detect anomalies and mitigate abuse; Regularly audit third-party dependencies and security policies to ensure they meet security standards and are not introducing vulnerabilities; Continuously monitor and log interactions with external APIs to detect potential security threats.
Ensure robust security when integrating third-party APIs by implementing strict validation, secure communication, and controlled interactions. For example, assess the API security posture of service providers before integration to verify compliance with best practices; Enforce secure communication channels (TLS) for all API interactions to prevent data interception and tampering; Validate and sanitize all incoming data from external APIs to eliminate potential injection risks before processing; Maintain a whitelist of trusted redirection destinations, ensuring that your application does not blindly follow unverified redirects, reducing the risk of phishing or malicious rerouting.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-15-10-01-01 | Evaluate api security posture of service providers | When selecting third-party service providers, thoroughly assess their API security posture to ensure that they adhere to strong security practices and meet your security requirements. | Preparation | Security Engineers, Product Managers |
| SSS-02-15-10-01-02 | Ensure secure communication with integrated apis | Ensure that all interactions with third-party APIs happen over secure communication channels (e.g., TLS) to protect the integrity and confidentiality of the data exchanged. | Development | Security Engineers, API Developers |
| SSS-02-15-10-01-03 | Validate and sanitize data from integrated apis | Validate and properly sanitize all data received from integrated third-party APIs before using it in your application, preventing malicious or unexpected data from being processed. | Development | Security Engineers, Backend Developers |
| SSS-02-15-10-01-04 | Maintain allowlist for api redirects | Maintain an allowlist of trusted locations to which integrated APIs may redirect your application. Avoid blindly following redirects to ensure that data is not sent to malicious destinations. | Development | Security Engineers, API Developers |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1851) OWASP Top 10 API Security Risk OWASP Top 10 API Security Risk |