{"stig":{"title":"Application Programming Interface (API) Security Requirements Guide","version":"1","release":"1"},"checks":[{"vulnId":"V-274497","ruleId":"SV-274497r1142303_rule","severity":"medium","ruleTitle":"The API must encrypt data in transit.","description":"An API must ensure sensitive tokens, including both internal and user-specific tokens, are transmitted over secure channels using HTTPS to protect them from being intercepted during transit. HTTPS encrypts the data being transmitted between the client and the server, ensuring tokens are securely transmitted and cannot be easily accessed by attackers, even if they intercept the communication (e.g., through man-in-the-middle attacks). This encryption is essential for maintaining the confidentiality and integrity of sensitive information, preventing unauthorized access to the API or its services. Without HTTPS, tokens are vulnerable to exposure, potentially allowing malicious actors to hijack sessions, impersonate users, or gain unauthorized access to internal systems, compromising both security and privacy.","checkContent":"API must verify sensitive tokens are transmitted over secure channels using HTTPS. This includes both internal and user-specific tokens.\n\nIf data being transmitted between the client and server is not using HTTPS, this is a finding.","fixText":"Build or configure the API server to automatically redirect any HTTP request to HTTPS. This ensures all communication with the API is encrypted by default.","ccis":["CCI-000068"]},{"vulnId":"V-274507","ruleId":"SV-274507r1143927_rule","severity":"medium","ruleTitle":"The API must be configured to use approved authorizations for access control.","description":"To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DOD-approved PKIs, all DOD systems (e.g., networks, web servers, and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. \n\nAccess control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. \n\nThis requirement is applicable to access control enforcement applications (e.g., authentication servers) and other applications that perform information and system access control functions.\n\nMethods include:\n- Basic Authentication (not recommended).\n- API Key Authentication.\n- TLS Encryption.\n- OAuth 2.0.\n- JWT-Based Authentication.\n- OpenID Connect (OIDC).","checkContent":"Confirm that the API enforces access control using approved authorization methods, such as token-based mechanisms (e.g., OAuth 2.0, JWT), role-based access control (RBAC), attribute-based access control (ABAC), or policy-based decisions provided by a centralized authorization service.\n\nEnsure the configuration aligns with DOD Zero Trust Reference Architecture Capability Authorization Enforcement, which requires that systems validate access requests using dynamic and contextual authorization decisions rather than relying solely on static permissions or network location.\n\nReview system documentation, API gateway configurations, and authorization policies to verify that access control decisions are:\n- Based on real-time evaluation of user identity, role, device posture, and other attributes.\n- Applied consistently across all API endpoints.\n- Logged for auditing and accountability.\n\nIf the API does not implement DOD-approved, context-aware authorization mechanisms as required under Zero Trust Capability or if authorization enforcement is not documented or configured, this is a finding.","fixText":"Build or configure the API to enforce access control using DOD-approved authorization mechanisms. Ensure that authorization decisions are dynamic and based on contextual factors (e.g., user role, device compliance, request attributes). \n\nUpdate system documentation to reflect the authorization strategy and verify integration with access management and logging systems to meet Zero Trust Capability requirements.","ccis":["CCI-000213"]},{"vulnId":"V-274517","ruleId":"SV-274517r1143512_rule","severity":"medium","ruleTitle":"The API must enable monitoring and alerts.","description":"Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. \n\nAudit records can be generated from various components within the application (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.\n\nDOD has defined the list of events for which the application will provide an audit record generation capability as the following: \n\n(i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n\n(ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and\n\n(iii) All account creation, modification, disabling, and termination actions.","checkContent":"Verify the API enables monitoring and alerts.\n\nConfirm that the API logs security-relevant events and that alerts are configured for abnormal or suspicious activity, in accordance with organization-defined logging and alerting standards.\n\nIf monitoring is not enabled, logs are not collected, or alerts are not generated for events as defined by organizational policy or standards, this is a finding.","fixText":"Build or configure the API to enable monitoring and alerts.","ccis":["CCI-000169"]},{"vulnId":"V-274519","ruleId":"SV-274519r1143513_rule","severity":"medium","ruleTitle":"The API Gateway must generate audit records when successful/unsuccessful attempts to access privileges occur.","description":"The API Gateway must generate audit records when successful or unsuccessful attempts to access privileges occur to ensure security, accountability, and compliance. By logging these events, the gateway can track and monitor who is trying to access sensitive or restricted resources, helping to detect potential unauthorized access attempts or malicious activity. Successful access logs provide a record of legitimate users or services that have been granted the appropriate permissions, while unsuccessful access attempts highlight potential security threats, such as brute-force attacks, credential stuffing, or unauthorized users attempting to bypass access controls. These audit records enable quick identification of suspicious patterns, making it easier to respond to potential breaches or policy violations in real time.","checkContent":"If an API Gateway is not in use, this is Not Applicable.\n\nVerify both successful and unsuccessful attempts to access privileges are configured to be logged. This may include user identity, timestamps, access attempts, and outcomes (success or failure).\n\nPerform various test cases to simulate both successful and unsuccessful access.\n\nAfter performing the test scenarios, access the logs generated by the API Gateway (or the centralized logging system) and check for entries related to authentication and authorization. \n\nCross-check the actual logging behavior with the organization’s auditing and security policies to verify the API Gateway meets required standards for logging successful and unsuccessful access attempts.\n\nIf the API Gateway does not generate audit records when successful/unsuccessful attempts to access privileges occur, this is a finding.","fixText":"Build or configure the API Gateway to enable logging successful/unsuccessful attempts to access privileges.","ccis":["CCI-000172"]},{"vulnId":"V-274520","ruleId":"SV-274520r1143514_rule","severity":"medium","ruleTitle":"The API must generate audit records when successful/unsuccessful attempts to access privileges occur.","description":"The API must generate audit records when successful or unsuccessful attempts to access privileges occur to ensure security, traceability, and accountability. By logging both successful and failed access attempts, the API creates a record that helps track who is attempting to access sensitive resources, and whether those attempts are authorized or not. This is critical for identifying potential security threats, such as unauthorized access, brute-force attacks, or credential stuffing, which could compromise the system. \n\nUnsuccessful attempts provide valuable insight into potential vulnerabilities or areas where attackers are trying to bypass security measures. Successful access logs, on the other hand, confirm the correct users or services are accessing resources within the intended permissions, ensuring access controls are working as expected.","checkContent":"Verify both successful and unsuccessful attempts to access privileges are configured to be logged. This may include user identity, timestamps, access attempts, and outcomes (success or failure).\n\nPerform various test cases to simulate both successful and unsuccessful access.\n\nAfter performing the test scenarios, access the logs generated by the API (or the centralized logging system) and check for entries related to authentication and authorization. \n\nCross-check the actual logging behavior with the organization’s auditing and security policies to verify the API meets required standards for logging successful and unsuccessful access attempts.\n\nIf the API does not generate audit records when successful/unsuccessful attempts to access privileges occur, this is a finding.","fixText":"Build or configure the API to enable logging successful/unsuccessful attempts to access privileges.","ccis":["CCI-000172"]},{"vulnId":"V-274522","ruleId":"SV-274522r1143515_rule","severity":"medium","ruleTitle":"The API Gateway must generate audit records of what type of events occurred.","description":"By recording the details of each event, the gateway can track and log specific actions such as authentication attempts, authorization checks, request routing, rate limiting, and error handling. These records provide valuable insights into the API's behavior, helping to detect unauthorized access, security breaches, or misuse of system resources.","checkContent":"If an API Gateway is not in use, this is Not Applicable.\n\nVerify the API Gateway generates audit records of what type of events occurred.\n\n1. Inspect the API Gateway's configuration settings and verify logging is enabled and audit records are being generated for key events such as authentication, authorization, data access, and errors.\n\n2. Make a valid API request and verify successful events are logged.\n\n3. Simulate system errors by causing the API to fail under specific conditions (e.g., database unavailability, timeout errors, internal exceptions).\n\n4. Check the audit or access logs in the API Gateway or logging platform (e.g., AWS CloudWatch, Splunk, ELK stack). Verify the logs contain entries for the triggered events.\n\n5. Inspect the log entries for the following:\n- Event Type: The event’s description or category (e.g., authentication attempt, data access, system error).\n\nIf the API Gateway does not generate audit records for the type of event, this is a finding.","fixText":"Build or configure the API Gateway to audit what type of events occurred.","ccis":["CCI-000130"]},{"vulnId":"V-274523","ruleId":"SV-274523r1143516_rule","severity":"medium","ruleTitle":"The API must monitor the usage of API keys to detect any anomalies.","description":"Monitoring the usage of API keys to detect anomalies is crucial for maintaining security, preventing abuse, and ensuring only authorized users or applications are accessing the system. \n\nAPI keys are used to authenticate and authorize requests to APIs, and if misused, can become a significant security vulnerability. By monitoring API key usage, unusual patterns can be detected quickly.\n\nAnomalies could indicate potential issues like compromised API keys, unauthorized third-party access, or bot activity. Early detection of such anomalies allows for timely action preventing further exploitation. \n\nMonitoring also helps enforce usage limits and detect overuse or abuse of API resources, which could impact system performance.","checkContent":"Verify the platform provides features to monitor API key usage, including tracking requests made with each key and flagging anomalies such as unexpected request patterns, usage from unusual geographic locations, abnormal request rates, or access to unauthorized endpoints. \n\nIf API key usage is not being monitored for anomalies, this is a finding.","fixText":"Build or configure the API to monitor API key usage and flag anomalies:\n\nEnable Logging: Log all API key usage, including timestamps, IP addresses, endpoints accessed, and request rates.\n\nDefine Normal Behavior: Establish a baseline for expected usage patterns (e.g., typical request rate, endpoints used, geographic regions).\n\nSet Thresholds: Configure thresholds for detecting anomalies such as excessive requests, access to unusual resources, or use from unexpected locations.\n\nIntegrate Monitoring Tools: Use API management or SIEM tools to analyze logs and trigger alerts on anomalous activity.\n\nAutomate Alerts: Set up real-time notifications or automated actions (e.g., temporary blocking) when anomalies are detected.","ccis":["CCI-000130"]},{"vulnId":"V-274524","ruleId":"SV-274524r1143517_rule","severity":"medium","ruleTitle":"The API must generate audit records of what type of events occurred.","description":"Without establishing what type of event occurred, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. \n\nAudit record content that may be necessary to satisfy the requirement of this policy includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.\n\nAssociating event types with detected events in the application and audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured application.\n\nMonitor the usage of API keys to detect any anomalies.","checkContent":"Verify the API generates audit records of what type of events occurred.\n\n1. Inspect the API’s configuration settings and verify logging is enabled and audit records are being generated for key events such as authentication, authorization, data access, and errors.\n\n2. Make a valid API request and verify successful events are logged.\n\n3. Simulate system errors under specific conditions (e.g., database unavailability, timeout errors, internal exceptions).\n\n4. Check the audit or access logs in the API or logging platform (e.g., AWS CloudWatch, Splunk, ELK stack). Verify that the logs contain entries for the triggered events.\n\n5. Inspect the log entries for the following:\n- Event Type: Look for the event’s description or category (e.g., authentication attempt, data access, system error).\n\nIf the API does not generate audit records for the type of event, this is a finding.","fixText":"Build or configure the API to audit what type of events occurred.","ccis":["CCI-000130"]},{"vulnId":"V-274525","ruleId":"SV-274525r1143929_rule","severity":"medium","ruleTitle":"The API must audit rate-limiting events.","description":"The API must audit rate-limiting events to ensure security, system stability, and fair resource usage. Rate limiting is essential for protecting the API from abuse, such as denial-of-service (DoS) attacks, where an attacker could overwhelm the system with excessive requests. By auditing rate-limiting events, the API can track when users or services exceed predefined thresholds, providing insight into potentially malicious behavior or misuse. These logs help detect patterns of abuse, such as attempts to bypass rate limits or automate excessive requests, allowing for timely intervention.","checkContent":"Verify the API audits rate-limiting events.\n\n1. Access the API configuration to ensure rate limiting is enabled. Rate limiting will specify how many requests are allowed per time period (e.g., 1,000 requests per hour).\n\n2. Verify rate-limiting events are configured to be logged. This includes events where a user exceeds their allowed request rate, triggering rate-limiting actions. \nThe API's audit or access log entries should:\n- Indicate when a rate limit was exceeded.\n- Include details about the API key or user who exceeded the limit.\n- Provide the rate-limiting threshold (e.g., \"rate limit exceeded: 1,000 requests per hour\").\n- Mention the specific API endpoint that was accessed.\n\n3. Review the organization's security policies to ensure rate-limiting events are properly audited as per requirements.\n\nIf the API is not auditing rate limiting events, this is a finding.","fixText":"Build or configure the API Gateway to enforce rate limits and log these events, including the thresholds for triggering rate limiting.","ccis":["CCI-000130"]},{"vulnId":"V-274526","ruleId":"SV-274526r1143552_rule","severity":"medium","ruleTitle":"The API Gateway must audit rate limiting events.","description":"The API Gateway must audit rate-limiting events to ensure robust security, performance, and compliance across all APIs it manages. Rate-limiting is a critical mechanism to protect APIs from abuse, such as denial-of-service (DoS) attacks or excessive resource consumption by malicious users. By auditing these events, the gateway can track and log instances where rate limits are exceeded, providing valuable insights into abnormal traffic patterns or attempts to bypass limits. This helps identify potential threats early, allowing for timely interventions. Additionally, auditing rate-limiting events allows for detailed logging and reporting, which are essential for troubleshooting, performance monitoring, and ensuring fair usage of API resources.","checkContent":"If an API Gateway is not in use, this is Not Applicable.\n\n1. Access the API Gateway's configuration to verify rate limiting is enabled. Rate limiting will specify how many requests are allowed per time period (e.g., 1000 requests per hour).\n\n2. Verify rate-limiting events are configured to be logged. This includes events where a user exceeds their allowed request rate, triggering rate-limiting actions.\n\n3. After triggering rate-limiting events, check the API's audit or access logs. Entries should:\n- Indicate when a rate limit was exceeded.\n- Include details about the API key or user who exceeded the limit.\n- Provide the rate-limiting threshold (e.g., \"rate limit exceeded: 1000 requests per hour\").\n- Mention the specific API endpoint that was accessed.\n\n4. Test the API to verify it behaves correctly when a rate limit is exceeded. For example, the API should return an appropriate status code (e.g., HTTP 429 Too Many Requests).\n\n5. Check the API Gateway logs to determine if the gateway logs rate-limiting events properly, including identifying when the threshold is exceeded and what actions are taken (e.g., temporary block).\n\n6. Review the organization's security policies to ensure rate-limiting events are properly audited as per requirements.\n\nIf the API Gateway is not auditing rate limiting events, this is a finding.","fixText":"Build or configure the API Gateway to enforce rate limits and log these events, including the thresholds for triggering rate limiting.","ccis":["CCI-000130"]},{"vulnId":"V-274527","ruleId":"SV-274527r1143553_rule","severity":"medium","ruleTitle":"The API Gateway must audit authentication and authorization information.","description":"The API Gateway must audit authentication and authorization information to ensure robust security, compliance, and accountability in access control. As the central entry point for all incoming API requests, the gateway is responsible for verifying the identity of users and ensuring they have the necessary permissions to access specific resources. By auditing authentication and authorization events, the gateway creates an audit trail that helps track and verify who accessed the API, when, and with what permissions. This is crucial for identifying and responding to potential security threats, such as unauthorized access attempts or privilege escalation. Auditing also helps detect suspicious patterns, such as repeated failed login attempts or attempts to access restricted endpoints, which could indicate an ongoing attack.","checkContent":"If an API Gateway is not in use, this is Not Applicable.\n\nVerify the API Gateway audits authentication and authorization information.\n\n1. Confirm audit logging is enabled for authentication and authorization events. This includes both successful and failed authentication attempts, as well as the authorization decisions (e.g., whether a user is granted or denied access).\n\n2. Verify the logs capture relevant authentication and authorization details.\n\n3. After performing tests, review the logs for entries related to authentication and authorization. Ensure that logs contain the appropriate level of detail (e.g., timestamps, user IDs, status codes).\n\nIf the API Gateway does not audit authentication and authorization information, this is a finding.","fixText":"Build or configure the API Gateway to log authentication and authorization events, including the appropriate level of detail (e.g., timestamps, user IDs, status codes).","ccis":["CCI-000130"]},{"vulnId":"V-274528","ruleId":"SV-274528r1143554_rule","severity":"medium","ruleTitle":"The API must audit authentication and authorization information.","description":"The API must audit authentication and authorization information to ensure proper security, accountability, and compliance. Auditing authentication and authorization events allows the API to track and log who accessed the system, what resources were accessed, and whether the user had the appropriate permissions. This is crucial for detecting unauthorized access, preventing privilege escalation, and identifying potential security threats, such as brute force attacks or credential theft. Auditing also provides a record of actions for accountability, helping to monitor user activity and ensuring that sensitive data or actions are only accessible to authorized individuals.","checkContent":"Verify the API generates audit records of what type of events occurred.\n\n1. Confirm audit logging is enabled for authentication and authorization events. This includes both successful and failed authentication attempts, as well as the authorization decisions (e.g., whether a user is granted or denied access).\n\n2. Verify the logs capture relevant authentication and authorization details.\n\n3. After performing tests, review the logs for entries related to authentication and authorization. Ensure that logs contain the appropriate level of detail (e.g., timestamps, user IDs, status codes).\n\nIf the API does not audit authentication and authorization information, this is a finding.","fixText":"Build or configure the API to log authentication and authorization events, including the appropriate level of detail (e.g., timestamps, user IDs, status codes).","ccis":["CCI-000130"]},{"vulnId":"V-274529","ruleId":"SV-274529r1143555_rule","severity":"medium","ruleTitle":"The API Gateway must audit exceptions and errors that occur during the processing.","description":"The API gateway must audit exceptions and errors that occur during processing to ensure robust security, reliable performance, and effective troubleshooting. As the central entry point for all incoming API requests, the gateway is responsible for managing traffic and routing requests to the appropriate backend services. Auditing errors and exceptions allows the gateway to capture critical issues such as request processing failures, system outages, or unexpected behaviors, providing insights into the health and stability of the entire API ecosystem. By logging these events, the gateway can help identify recurring issues, misconfigurations, or security vulnerabilities that might otherwise go unnoticed. This is essential for detecting potential attacks, such as denial-of-service (DoS) attempts or malicious behavior that exploits system flaws.","checkContent":"If an API Gateway is not in use, this is Not Applicable.\n\nVerify the API Gateway audits exceptions and errors that occur during the processing.\n\n1. Inspect the API Gateway logs to ensure they capture exception and error events, including error codes, messages, and stack traces.\n\n2. Simulate errors (e.g., invalid requests or server failures) and verify these are logged with relevant details like timestamps and error types.\n\n3. Verify the API Gateway is configured to log exceptions and errors with sufficient detail for troubleshooting and analysis.\n\n4. Review the API Gateway documentation support to ensure proper auditing of exceptions and errors is enabled.\n\nIf the API Gateway does not audit exceptions and errors, this is a finding.","fixText":"Build or configure the API Gateway to log errors and exceptions, including the level of detail, such as timestamps, error type, and affected resources.","ccis":["CCI-000130"]},{"vulnId":"V-274530","ruleId":"SV-274530r1143557_rule","severity":"medium","ruleTitle":"The API must audit exceptions and errors that occur during the processing.","description":"Without establishing what type of event occurred, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. \n\nAudit record content that may be necessary to satisfy the requirement of this policy includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.\n\nAssociating event types with detected events in the application and audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured application.\n\nMonitor the usage of API keys to detect any anomalies.","checkContent":"Verify the API audits exceptions and errors that occur during the processing.\n\n1. Inspect the API's logs to ensure they capture exception and error events, including error codes, messages, and stack traces.\n\n2. Simulate errors (e.g., invalid requests or server failures) and verify these are logged with relevant details like timestamps and error types.\n\n3. Ensure the API is configured to log exceptions and errors with sufficient detail for troubleshooting and analysis.\n\n4. Review the API's documentation support to ensure proper auditing of exceptions and errors is enabled.\n\nIf the API does not audit exceptions and errors, this is a finding.","fixText":"Build or configure the API to log exceptions and errors with sufficient detail for troubleshooting and analysis.","ccis":["CCI-000130"]},{"vulnId":"V-274531","ruleId":"SV-274531r1143559_rule","severity":"medium","ruleTitle":"The API Gateway must audit execution time and performance metrics.","description":"The API Gateway must audit execution time and performance metrics to ensure efficient traffic management, optimize resource usage, and maintain a high-quality user experience across all services. As the entry point for all incoming API requests, the gateway plays a crucial role in routing traffic, load balancing, and handling cross-cutting concerns like security and rate limiting. By auditing execution time and performance metrics, the gateway can track the response times of both it and the backend services, identifying potential bottlenecks, latency issues, or inefficient processing. This enables timely intervention to resolve performance problems before they impact users or cause system failures.\n\nAlong with knowing when an event occurred, monitoring execution time can help detect unusual patterns, such as distributed denial-of-service (DDoS) attacks or misconfigured services, which could slow down the system.","checkContent":"If an API Gateway is not in use, this is Not Applicable.\n\nVerify the API Gateway audits execution time and performance metrics.\n\n1. Inspect the API Gateway's logs to verify they capture performance-related data, such as execution times, request latency, and throughput.\n\n2. Simulate various requests and monitor the execution times, verifying performance metrics are logged for each request or operation.\n\n3. Verify the API Gateway is configured to log execution times and track key performance metrics, including thresholds for alerts.\n\n4. Review the API Gateway's documentation to ensure auditing of execution time and performance metrics is properly configured and operational.\n\nIf the API Gateway is not auditing execution time and performance metrics, this is a finding.","fixText":"Build or configure the API Gateway to log execution times and track key performance metrics, including thresholds for alerts.","ccis":["CCI-000130"]},{"vulnId":"V-274532","ruleId":"SV-274532r1143561_rule","severity":"medium","ruleTitle":"The API must audit execution time and performance metrics.","description":"The API must audit execution time and performance metrics to ensure optimal operation, detect bottlenecks, and maintain a high level of service reliability. \n\nMonitoring and logging execution time allows the API to track how long each request takes to process, helping to identify slow endpoints or inefficient processing. \n\nBy auditing performance metrics, the API can detect patterns that indicate potential issues, such as sudden spikes in latency or resource consumption, which may be early signs of performance degradation or impending system failures.\n\nAlong with knowing when an event occurred, monitoring execution time can highlight unusual patterns, such as denial-of-service (DoS) attacks, where the API is deliberately slowed down by an overwhelming number of requests.","checkContent":"Verify the API audits execution time and performance metrics.\n\n1. Inspect the API's logs to ensure they capture execution times, request latency, and other performance metrics.\n\n2. Simulate various requests and verify execution time and performance metrics are logged correctly.\n\n3. Verify the API is configured to track and log performance data, including response times and throughput.\n\n4. Review the API's documentation to ensure execution time and performance auditing is enabled.\n\nIf the API is not auditing execution time and performance metrics, this is a finding.","fixText":"Build or configure the API to track and log performance data, including response times and throughput.","ccis":["CCI-000130"]},{"vulnId":"V-274533","ruleId":"SV-274533r1143563_rule","severity":"medium","ruleTitle":"The API Gateway must audit request and response details (such as method, URL, headers, body, status, etc.).","description":"The API Gateway must audit request and response details to ensure robust security, efficient troubleshooting, and compliance with regulations. As the central point for handling incoming traffic, the gateway is responsible for managing authentication, authorization, routing, and applying policies across all services. By auditing request and response details, the gateway can monitor for potential security threats, such as unauthorized access attempts, data tampering, or malicious activities like SQL injection and cross-site scripting (XSS). \n\nDetailed logs provide valuable information for troubleshooting issues, enabling quick identification of problematic requests, errors, or performance bottlenecks, which can be essential for maintaining system reliability.","checkContent":"If an API Gateway is not in use, this is Not Applicable.\n\nVerify the API audits execution time and performance metrics.\n\n1. Inspect the API Gateway's logs to verify they capture details of incoming requests and outgoing responses, including headers, body content, and status codes.\n\n2. Simulate various requests and verify that both request and response details are being logged correctly, including any data passed and the response outcome.\n\n3. Verify the API Gateway is configured to log the necessary request and response details, such as the type of request, request parameters, and response status.\n\n4. Review the API Gateway's documentation to ensure proper auditing of request and response details is enabled.\n\nIf the API Gateway is not auditing request and response detail, this is a finding.","fixText":"Build or configure the API Gateway to log the necessary request and response details such as method, URL, headers, body, status, etc.","ccis":["CCI-000130"]},{"vulnId":"V-274534","ruleId":"SV-274534r1143565_rule","severity":"medium","ruleTitle":"The API must audit request and response details (such as method, URL, headers, body, status, etc.).","description":"By logging request and response data, the API can track the flow of information between clients and the system, providing a detailed audit trail that helps detect and analyze potential security incidents, such as unauthorized access attempts, data manipulation, or injection attacks.","checkContent":"Verify the API audits request and response details.\n\n1. Inspect the API's logs to verify they capture details of incoming requests and outgoing responses, including headers, body content, and status codes.\n\n2. Simulate various requests and verify that both request and response details are being logged correctly, including any data passed and the response outcome.\n\n3. Verify the API is configured to log the necessary request and response details, such as the type of request, request parameters, and response status.\n\n4. Review the API's documentation to ensure proper auditing of request and response details is enabled.\n\nIf the API is not auditing request and response detail, this is a finding.","fixText":"Build or configure the API to log the necessary request and response details such as method, URL, headers, body, status, etc.","ccis":["CCI-000130"]},{"vulnId":"V-274537","ruleId":"SV-274537r1143570_rule","severity":"medium","ruleTitle":"All defined API elements must be documented.","description":"All defined API elements and their security-relevant configurations must be documented and enforced, ensuring compliance with the organization's approved security baselines.\n\nIdentifying all API elements that must be logged is essential for security, monitoring, and threat detection. \n\nDocumenting and enforcing security-relevant configurations for all defined API elements ensures consistency, reduces misconfigurations, and supports compliance with organizational security baselines. This practice enhances system integrity, simplifies audits, and helps prevent vulnerabilities caused by undocumented or insecure API behaviors.","checkContent":"To identify APIs in use:\n\nAnalyze application code for API calls, URLs, and authentication keys in frontend and backend components. \n\nUse network monitoring tools to capture API traffic in real time. \n\nCheck browser DevTools (Network tab) for active API requests in web applications.\n\nReview server and API gateway logs (e.g., AWS CloudWatch, Nginx logs) to track API calls and usage patterns. \n\nInspect configuration files, environment variables, and documentation for references to external or internal APIs.\n\nIf any defined API elements or their security-relevant configurations are not documented and enforced in accordance with the organization's approved security baselines, this is a finding.","fixText":"Update the documentation to include all defined API elements and their security-relevant configurations. Ensure each element is properly logged and monitored in accordance with the organization's approved security baselines.","ccis":["CCI-000133"]},{"vulnId":"V-274556","ruleId":"SV-274556r1143589_rule","severity":"medium","ruleTitle":"API keys must be configured with usage restrictions.","description":"Requiring every API key to have restrictions for both the applications and the specific set of APIs minimizes the attack surface and ensures that each key is used only in the intended context. By limiting an API key's use to specific IP addresses, devices, or applications (e.g., mobile apps, web apps), the risk of unauthorized access is greatly reduced, even if a key is compromised. It prevents malicious actors from using stolen keys on untrusted platforms or for unapproved purposes, such as accessing sensitive data or performing actions outside the scope of the original API access.\n\nRestricting an API key to only the necessary APIs or endpoints reduces the potential damage if a key is leaked. It ensures each API key has minimal privileges (principle of least privilege), limiting what it can do or access. This granular control helps enforce better access management and facilitates audit trails by defining clear boundaries for how keys should behave.","checkContent":"Review the API key configurations. If any API keys lack defined usage restrictions (IP address filtering, endpoint access limitations, and environment scoping) this is a finding.","fixText":"Update the API key configurations to include appropriate usage restrictions (limiting access by IP address, allowed endpoints, request methods, and environment scope) in accordance with organizational defined standards.","ccis":["CCI-000381"]},{"vulnId":"V-274557","ruleId":"SV-274557r1143590_rule","severity":"medium","ruleTitle":"The API must limit the exposure of endpoints.","description":"Exposing too many API endpoints, which are specific URLs or paths that allow clients to interact with various functions or data within the system, increases the attack surface. This exposure makes the API more vulnerable to unauthorized access, data breaches, and distributed denial-of-service (DDoS) attacks. By restricting access to only necessary endpoints, the API ensures that only authenticated and authorized users can reach sensitive data or critical operations. Limiting the number of exposed endpoints reduces system complexity, enhances performance, and enables more effective enforcement of rate limits and monitoring controls.","checkContent":"Review the API documentation and configuration. If any endpoints (i.e., URLs or paths that handle client requests) are publicly accessible without a valid business or security justification, or if unnecessary endpoints are exposed, this is a finding.","fixText":"Build or configure the API to limit the endpoint against improper exposure.","ccis":["CCI-000381"]},{"vulnId":"V-274559","ruleId":"SV-274559r1143592_rule","severity":"medium","ruleTitle":"The API must use an approved DOD enterprise identity, credential, and access management (ICAM) solution to uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).","description":"To ensure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. This is typically accomplished via the use of a user store, which is either local (OS-based) or centralized (LDAP) in nature. However, DODI 8520.03 now requires that applications use an approved DOD enterprise (E-ICAM) solution whenever the ICAM solution addresses information system needs. Where the ICAM solution has been evaluated and found to not meet the needs of information system owners, information system owners must reevaluate decisions to use locally managed solutions and transition to DOD enterprise ICAM solutions to the maximum extent possible as the enterprise ICAM solutions mature.","checkContent":"Review the API documentation and interview the API administrator to determine access methods to the API.\n\nAttempt to access the API and confirm that an approved DOD enterprise ICAM solution is required for an external client to establish initial access to the API. Authentication of subsequent calls to the API may be accomplished using a time-limited credential such as an API key or JWT.\n\nIf the API does not use an approved DOD enterprise ICAM solution for external clients to establish initial access, this is a finding.","fixText":"Configure the API to use an approved DOD enterprise ICAM solution.","ccis":["CCI-000764"]},{"vulnId":"V-274600","ruleId":"SV-274600r1143633_rule","severity":"medium","ruleTitle":"The API must protect Session IDs via encryption.","description":"Encrypting Session IDs protects them from interception and unauthorized access, preventing session hijacking and ensuring the confidentiality and integrity of user sessions.","checkContent":"Verify the API protects Session IDs.\n\nReview the API documentation and configuration.\n\nInterview the API administrator and obtain implementation documentation identifying system architecture.\n\nIdentify the API communication paths. This includes system-to-system communication and client-to-server communication that transmit session identifiers over the network.\n\nHave the API administrator identify the methods and mechanisms used to protect the API session ID traffic. Acceptable methods include SSL/TLS both one-way and two-way and VPN tunnel.\n\nThe protections must be implemented on a point-to-point basis based upon the architecture of the API.\n\nFor example, a web API hosting static data will provide SSL/TLS encryption from web client to the web server. More complex designs may encrypt from API server to API server (if applicable) and API server to database as well.\n\nIf the API session IDs are unencrypted across network segments, this is a finding.","fixText":"Build or configure the API to protect session IDs from interception or from manipulation.","ccis":["CCI-001184"]},{"vulnId":"V-274603","ruleId":"SV-274603r1143636_rule","severity":"medium","ruleTitle":"The API keys must be securely generated using a FIPS-validated Random Number Generator (RNG).","description":"Sequentially generated session IDs can be easily guessed by an attacker. Employing the concept of randomness in the generation of unique session identifiers helps to protect against brute-force attacks to determine future session identifiers.\n\nUnique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. \n\nDRBGs (Deterministic Random Bit Generators) are cryptographic algorithms that generate random-looking bits using a deterministic process seeded with high-quality entropy. The DRBGs Hash_DRBG, HMAC_DRBG, and CTR_DRBG are recommended for use with RNGs.","checkContent":"This requirement is applicable only to devices that use a web interface for device management.\n\nVerify the API keys are securely generated using a FIPS-validated RNG.\n\nReview the API documentation and interview the API administrator.\n\nIdentify the cryptographic modules utilized by the API for key generation.\n\nIdentify the cryptographic service provider utilized by the API and reference the NIST validation website to ensure the algorithms utilized are approved: https://csrc.nist.gov/projects/cryptographic-module-validation-program.\n\nIf the API does not use a FIPS 140-3-approved RNG, this is a finding.","fixText":"This requirement is applicable only to devices that use a web interface for device management.\n\nBuild or configure the API to use FIPS 140-3-validated cryptographic modules when the API implements RNGs for key generation.","ccis":["CCI-001188"]},{"vulnId":"V-274606","ruleId":"SV-274606r1143639_rule","severity":"medium","ruleTitle":"The API implementation must use FIPS-validated encryption and hashing algorithms to protect the confidentiality and integrity of API keys.","description":"Confidentiality and integrity protections are intended to address the confidentiality and integrity of system information at rest (e.g., network device rule sets) when it is located on a storage device within the network device or as a component of the network device. This protection is required to prevent unauthorized alteration, corruption, or disclosure of information when not stored directly on the network device.\n\nStore API keys securely, avoiding plaintext storage.","checkContent":"Verify that the API implementation uses FIPS-validated encryption and hashing algorithms to protect API keys. If non-FIPS-validated algorithms are used, or if encryption/hashing is absent, this is a finding.","fixText":"Identify data elements that require protection. Document the data types and specify protection requirements and methods used.","ccis":["CCI-001199"]},{"vulnId":"V-274607","ruleId":"SV-274607r1143640_rule","severity":"high","ruleTitle":"The API must encrypt sensitive cached data.","description":"API caching is often used to cache endpoint responses. Caching will reduce the number of calls made to the endpoint and can improve application performance. Cached data can also include sensitive information that must be protected.","checkContent":"Verify the API encrypts sensitive data when it is cached.\n\nIf the API does not encrypt sensitive cached data, this is a finding.","fixText":"Build or configure the API to encrypt sensitive data when cached.","ccis":["CCI-001199"]},{"vulnId":"V-274612","ruleId":"SV-274612r1143931_rule","severity":"medium","ruleTitle":"The API must employ throttling.","description":"The API must employ throttling to limit the effects of information flooding types of denial-of-service (DoS) attacks. DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. \n\nIn the case of application DoS attacks, care must be taken when designing the application to ensure the application makes the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time. \n\nThe methods employed to meet this requirement will vary depending upon the technology the application uses. However, a variety of technologies exist to limit or, in some cases, eliminate the effects of application-related DoS attacks. Employing increased capacity and bandwidth combined with specialized application layer protection devices and service redundancy may reduce the susceptibility to some DoS attacks.","checkContent":"Review the API architecture documentation and identify solutions that provide API DoS protections. \n\nVerify the API employs throttling to limit the effects of information flooding attacks.\n\nThis includes:\n- Requests per second.\n- Sliding window algorithm.\n- Request queues.\n- Reduce parallelism and call frequency.\n\nIf the API does not employ throttling to limit the effects of information flooding attacks, this is a finding.","fixText":"Build or configure the API to employ throttling to limit the effects of information flooding attacks.","ccis":["CCI-001095"]},{"vulnId":"V-274613","ruleId":"SV-274613r1143646_rule","severity":"medium","ruleTitle":"The API must specify allowed origins when using Cross-Origin Resource Sharing (CORS).","description":"Invalid user input occurs when a user inserts data or characters into an application's data entry fields and the application is unprepared to process that data. This results in unanticipated application behavior, potentially leading to an application or information system compromise. Invalid input is one of the primary methods employed when attempting to compromise an application. \n\nChecking the valid syntax and semantics of information system inputs (e.g., character set, length, numerical range, and acceptable values) verifies that inputs match specified definitions for format and content. Software applications typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If software applications use attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata. Consequently, the module or component that receives the tainted output will perform the wrong operations or otherwise interpret the data incorrectly. Prescreening inputs prior to passing to interpreters prevents the content from being unintentionally interpreted as commands. Input validation helps to ensure accurate and correct inputs and prevent attacks such as cross-site scripting and a variety of injection attacks.","checkContent":"If CORS is not in use, this requirement is not applicable.\n\nVerify the API specifies origins when using CORS.\n\nIf the API is using CORS and does not specify allowed origins, this is a finding.","fixText":"Build or configure the API to specify allowed origins when using CORS.","ccis":["CCI-001310"]},{"vulnId":"V-274615","ruleId":"SV-274615r1143648_rule","severity":"medium","ruleTitle":"The API must not disclose sensitive data in error messages.","description":"Any application providing too much information in error messages risks compromising the data and security of the application and system. The structure and content of error messages must be carefully considered by the organization and development team. \n\nThe extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements. Information that could be exploited by adversaries includes, for example, erroneous logon attempts with passwords entered by mistake as the username, mission/business information that can be derived from (if not stated explicitly by) information recorded, and personal information, such as account numbers, social security numbers, and credit card numbers.\n\nMask or redact sensitive data in API responses.","checkContent":"Review the API documentation and interview the API administrator for details regarding how the API displays error messages.\n\nUtilize the API as a nonprivileged user and attempt to execute functionality that will generate error messages.\n\nReview the error messages displayed to ensure no sensitive information is provided to end users.\n\nIf error messages are designed to provide users with just enough detail to pass along to support staff to aid in troubleshooting date, time, or other generic information, this is not a finding.\n\nIf variable names, SQL strings, system path information, or source or program code are displayed in error messages sent to nonprivileged users, this is a finding.","fixText":"Build or configure the API to not send error messages containing system information or sensitive data to users.\n\nUse generic error messages.","ccis":["CCI-001312"]},{"vulnId":"V-274643","ruleId":"SV-274643r1143676_rule","severity":"medium","ruleTitle":"Access to API privileged features and functions must be restricted.","description":"Preventing nonprivileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges. \n\nPrivileged functions include, for example, establishing accounts, performing system integrity checks, or administering cryptographic key management activities. Nonprivileged users are individuals that do not possess appropriate authorizations.\n\nOne method to meet this requirement is to separate APIs into roles and functions to limit access based on need.","checkContent":"Review access controls for API privileged features and functions (administrative operations, configuration management, data modification, and access to sensitive information).\n\nIf unauthorized users can access any of these privileged capabilities, this is a finding.","fixText":"Build or configure the API to Implement and enforce access controls that restrict privileged API features and functions (administrative actions, configuration changes, data modification, and sensitive data access) to authorized users only.","ccis":["CCI-002235"]},{"vulnId":"V-274672","ruleId":"SV-274672r1143705_rule","severity":"medium","ruleTitle":"The API must require periodic reauthentication.","description":"Without reauthentication, resources may be accessed without authorization. \n\nWhen APIs provide the capability to change security roles or escalate the functional capability of the application, it is critical the user reauthenticate.\n\nIn addition to the reauthentication requirements associated with session locks, organizations may require reauthentication of individuals and/or devices in other situations, including (but not limited to) the following circumstances.\n\n(i) When authenticators change; \n(ii) When roles change; \n(iii) When security categories of information systems change; \n(iv) When the execution of privileged functions occurs; \n(v) After a fixed period of time (ex. 24 hours); or\n(vi) Periodically.\n\nWithin the DOD, the minimum circumstances requiring reauthentication are privilege escalation and role changes.","checkContent":"Verify the API requires periodic reauthentication.\n\nIf the API does not require reauthentication periodically, this is a finding.","fixText":"Build or configure the API to require reauthentication periodically.","ccis":["CCI-002038"]},{"vulnId":"V-274677","ruleId":"SV-274677r1143710_rule","severity":"medium","ruleTitle":"The API must have a mechanism for cache invalidation when using cache policy data.","description":"Temporarily storing (caching) information like access control rules or system configuration policies in memory or a local store allows the system to avoid repeatedly querying a centralized policy engine or database. This makes the system faster and more resilient to outages. Caching policy data helps improve performance, reduce latency, and maintain system resilience. It is essential to carefully manage the consistency of cached data, ensure it is up-to-date, and implement mechanisms for cache invalidation when policies change.","checkContent":"Verify the API has a mechanism for cache invalidation when using cache policy data. \n\nIt may be appropriate to allow microservices to cache policy data; however, this cache must only be relied upon when an access server is unavailable. The cached data must expire after a duration defined by the organization and appropriate for the specific environment/infrastructure. \n\nIf the API is not configured to expire cache policy data, this is a finding.","fixText":"Build or configure the API to expire the cache policy data.","ccis":["CCI-002007"]},{"vulnId":"V-274678","ruleId":"SV-274678r1143711_rule","severity":"medium","ruleTitle":"When stateless authentication tokens are used, the API must configure them with appropriate security settings.","description":"When stateless authentication tokens (e.g., JSON Web Tokens [JWT]) are used by implementing shared libraries associated with a microservice, security precautions must be observed.\n\nThe API must configure tokens for stateless authentication to ensure secure validation, prevent unauthorized access, and maintain integrity without relying on server-side sessions.","checkContent":"Verify the API configures tokens with the appropriate security settings, when stateless authentication tokens are used.\n\n1. The token expiry times must be as short as possible since they determine the duration of the session and an active session cannot be revoked.\n\nIf an expiration time is not configured in accordance with organizational defined limits, this is a finding. \n\n2. The token secret key must not be a part of the library code; it must be a dynamic variable represented by an environmental variable or specified in an environment data file.\n\nCheck if the token secret is included in requests that originate from the library. If a token secret key is part of library code, this is a finding.\n\n3. The key value must be stored in a data vault solution. Check application configuration files. Check environment variables referencing vault storage.\n\nIf a key value is not stored in a data vault solution, this is a finding.","fixText":"Build or configure tokens for stateless authentication to ensure secure validation, prevent unauthorized access, and maintain integrity without relying on server-side sessions.\n\n1. Configure expiration time in accordance with organizational defined limits.\n\n2. Configure the token secret key to be a dynamic variable represented by an environmental variable or specified in an environment data file.\n\n3. Store the key value in a data vault solution.","ccis":["CCI-002007"]},{"vulnId":"V-274679","ruleId":"SV-274679r1143712_rule","severity":"medium","ruleTitle":"The API's internal authorization tokens must not be provided back to the user.","description":"An API's internal authorization tokens must not be provided back to the user because exposing these tokens increases the risk of unauthorized access to sensitive backend systems or services. Internal tokens are meant to authenticate and authorize the API's internal operations and must remain private to maintain the security of the application architecture. If these tokens are leaked or made accessible to users, malicious actors could exploit them to gain elevated privileges, bypass security mechanisms, or launch attacks such as privilege escalation or token reuse. By keeping internal tokens hidden from the user, potential misuse is prevented, and the integrity of application's security model is protected.","checkContent":"Verify the API's internal authorization tokens are not provided back to the user.\n\nInspect API responses: Look at the API responses for any authorization tokens (e.g., JSON Web Tokens [JWT] tokens, session tokens, API keys) that may be included in the response body or headers. Verify sensitive tokens are not being returned as part of a successful request or error response.\n\nAudit API documentation: Review the API documentation to see if the token is explicitly mentioned as being returned to the user.\n\nIf internal tokens are part of any public documentation for user-facing APIs, this is a finding.","fixText":"Review the API and authentication codebase. Remove internal tokens being passed around or exposed at any point in the code.","ccis":["CCI-002007"]},{"vulnId":"V-274680","ruleId":"SV-274680r1143713_rule","severity":"medium","ruleTitle":"API access tokens must be configured to expire.","description":"API access tokens are short-lived credentials used to authenticate and authorize API requests. They are included in request headers to grant access to protected resources without requiring user credentials each time. To enhance security, they must have expiration times and require renewal through refresh tokens.\n\nIf cached authentication information is out of date, the validity of the authentication information may be questionable.","checkContent":"Verify API access tokens are configured to expire according to organizational defined parameters.\n\nIf API access tokens are not configured to expire according to organizational defined parameters, this is a finding.","fixText":"Build or configure API access tokens to expire according to organizational defined parameters.","ccis":["CCI-002007"]},{"vulnId":"V-274681","ruleId":"SV-274681r1143714_rule","severity":"medium","ruleTitle":"API refresh tokens must be configured to expire.","description":"By setting an expiration date on refresh tokens, the potential for abuse of a leaked token is reduced. Additionally, limiting their lifespan ensures tokens are regularly rotated, forcing users to reauthenticate periodically, which strengthens overall security and ensures access rights are up to date. This practice helps mitigate risks such as unauthorized access and session hijacking.","checkContent":"Verify API refresh tokens are configured to expire according to organizational defined parameters.\n\nIf API refresh tokens are not configured to expire according to organizational defined parameters, this is a finding.","fixText":"Build or configure API refresh tokens to expire according to organizational defined parameters.","ccis":["CCI-002007"]},{"vulnId":"V-274682","ruleId":"SV-274682r1143925_rule","severity":"medium","ruleTitle":"The API must enforce per-client rate limits.","description":"Configuring rate limits on API keys helps prevent abuse, mitigates denial-of-service attacks, and ensures fair usage of resources by restricting the number of requests an entity can make within a set timeframe.","checkContent":"Review the API gateway, reverse proxy, or service configuration to confirm that rate limiting is implemented on a per-client basis. A \"client\" may be identified using API keys, OAuth tokens, IP addresses, or other unique identifiers.\n\nVerify that:\n- Each client has an independent rate limit (e.g., requests per second/minute/hour).\n- Limits are enforced consistently across API endpoints.\n- Clients exceeding the limit receive appropriate error responses (e.g., HTTP 429 Too Many Requests).\n- The rate limiting configuration aligns with organizational performance and security policies.\n\nAcceptable evidence may include Gateway/service configuration files or dashboards (e.g., AWS API Gateway, NGINX).\n\nAPI documentation defining rate limits per client.\n\nLogs showing enforcement of limits for individual clients.\n\nIf the API does not enforce per-client rate limits, or if limits are global, improperly configured, or unenforced, this is a finding.","fixText":"Build or configure per-client rate limiting on the API using a gateway, reverse proxy, or API management platform. Identify clients using unique identifiers (such as API keys, access tokens, or IP addresses) and configure rate limits to ensure fair usage and prevent abuse.\n\nEnsure that:\n- Each client has a defined threshold for request rates.\n- Limits are enforced dynamically.\n- Clients exceeding limits receive appropriate error responses.\n\nUpdate system documentation to reflect the implemented rate-limiting policy and enforcement mechanisms.","ccis":["CCI-001095"]},{"vulnId":"V-274697","ruleId":"SV-274697r1143731_rule","severity":"medium","ruleTitle":"Clients must be configured to route requests through a single API gateway that enforces the association and transmission of organization-defined security attributes with each request.","description":"Using a single API gateway URL for all client communications centralizes key aspects of security management, such as authentication, rate limiting, and logging. It also protects backend services by acting as a barrier and reduces exposure to potential attacks. \n\nBy routing all client requests through a single entry point, the API gateway centralizes the handling of authentication, authorization, and request routing, reducing the complexity of individual APIs needing to handle these concerns independently. Ensuring that security measures, such as token validation and rate limiting, can be consistently enforced across all services without requiring each backend API to independently manage these functions. \n\nIt also simplifies the management of API versions and access policies, as updates or changes can be applied at the gateway level rather than modifying each individual API. Using a single URL allows the gateway to aggregate and forward requests to the appropriate backend services, optimizing traffic routing and improving performance. This approach enhances security by providing a single point of control and monitoring, making it easier to detect and respond to potential threats, and improves scalability by allowing the API infrastructure to handle growing traffic more efficiently.","checkContent":"Note: The authorizing official (AO) may conduct a risk assessment if not using an API Gateway.\n\nCheck Client API Endpoints: \nExamine the client-side code (whether a web app, mobile app, or another service) to confirm that all API calls are configured to point to a single gateway URL.\n\nReview the access logs or traffic logs of the API gateway to determine where incoming requests are coming from. Verify all requests are originating from the expected single API gateway endpoint.\n\nIf the API is not configured to route requests through a single, authorized API Gateway endpoint, this is a finding.","fixText":"Clients must be configured to call a single API gateway URL rather than accessing backend services directly.","ccis":["CCI-002455"]},{"vulnId":"V-274707","ruleId":"SV-274707r1143741_rule","severity":"medium","ruleTitle":"The API must use a gateway.","description":"API Gateway acts as a centralized point for managing and securing API traffic, enhancing the overall security posture of an API ecosystem. \n\nThe API Gateway helps protect backend services by abstracting and securing access to APIs, enabling features such as authentication, authorization, rate limiting, and IP whitelisting. It can enforce security policies like SSL/TLS encryption, protect against distributed denial-of-service (DDoS) attacks, and log and audit all requests for compliance and monitoring. \n\nIt simplifies the management of API keys, tokens, and other credentials, reducing the exposure of sensitive information. By consolidating security functions in the API Gateway, organizations can better manage and enforce consistent security measures across all API endpoints, ensuring a stronger defense against potential threats.","checkContent":"Note: The authorizing official (AO) may conduct a risk assessment if not using an API Gateway.\n\nThe API must be routed through a gateway that enforces protections against denial-of-service (DoS) attacks such as rate limiting, request throttling, and anomaly detection in accordance with organization-defined thresholds.\n\nIf the API does not use a gateway, this is a finding.","fixText":"Build or configure the API to use a gateway.","ccis":["CCI-002385"]},{"vulnId":"V-274709","ruleId":"SV-274709r1143744_rule","severity":"high","ruleTitle":"The amount of data returned by the API must be restricted.","description":"Restrict exposing excessively large sets of data that could be used to discover vulnerabilities or extract sensitive information. This will protect sensitive information and prevent performance bottlenecks caused by returning large, unnecessary datasets.","checkContent":"Verify the amount of data returned by the API is restricted.\n\nCheck API endpoints: \nReview the various API endpoints and the data they return. Look for endpoints that might expose excessively large datasets or sensitive information (e.g., entire user lists, full transaction histories).\n\nIf the API exposes unusually large volumes of data in a single response (entire datasets, unrestricted record sets, or bulk exports without proper limits or pagination) this is a finding.","fixText":"Ensure API responses are small and contain only the data necessary for the client's request.\n\nTo ensure that the amount of data returned by an API is appropriately restricted, implement and test measures like pagination, field filtering, query parameters, server-side limits, and proper access control.","ccis":["CCI-002418"]},{"vulnId":"V-274710","ruleId":"SV-274710r1143745_rule","severity":"high","ruleTitle":"The API must use TLS version 1.2 at a minimum.","description":"Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. \n\nThis requirement applies only to those applications that are either distributed or can allow access to data nonlocally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPsec.\n\nCommunication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.","checkContent":"Verify the API uses TLS version 1.2 at a minimum.\n\nReview the API documentation and interview the API administrator.\n\nIdentify API clients, servers and associated network connections including API networking ports.\n\nReview API documents for instructions or guidance on configuring API encryption settings.\n\nVerify the API is configured to enable encryption protections for data in accordance with the data protection requirements. If no data protection requirements exist, ensure all API data is encrypted.\n\nIf the API does not utilize TLS or another approved encryption mechanism to protect the confidentiality and integrity of transmitted information, this is a finding.","fixText":"Build or configure all of the API systems to require TLS (version 1.2 or higher) for all communication encryption in accordance with data protection requirements.","ccis":["CCI-002418"]},{"vulnId":"V-274712","ruleId":"SV-274712r1143748_rule","severity":"medium","ruleTitle":"The API must audience-restrict access tokens in accordance with organization-defined identification and authentication policy.","description":"An API must audience-restrict access tokens to ensure tokens can only be used by the intended recipient or service. Audience restriction involves embedding an \"audience\" claim in the token, which specifies the exact API or service authorized to accept it. \n\nWithout an API gateway to enforce this, the API itself must validate the audience claim to prevent tokens from being used maliciously by unauthorized services. This restriction helps protect the API from unauthorized access and ensures that tokens are not intercepted and misused in other parts of the system, enhancing overall security by limiting the scope of each token to its intended purpose.","checkContent":"Review the API's token issuance process, specifically for access tokens (e.g., JWTs or OAuth2 tokens).\n\nInspect the aud (audience) claim in the access tokens to verify that it is present and correctly populated with the intended audience identifier(s).\n\nConfirm that audience restrictions align with the organization's identification and authentication policy, ensuring that tokens are scoped only to authorized APIs, services, or clients.\n\nReview access control and validation logic in the API or resource server to ensure that incoming tokens are validated against the expected audience value.\n\nInterview the system owner or developer to verify how audience values are defined, issued, and enforced.\n\nIf access tokens are not audience-restricted or if the audience values do not comply with the organization-defined policy, this is a finding.","fixText":"Build or configure the API to audience restrict access tokens in accordance with organization-defined identification and authentication policy.","ccis":["CCI-002420"]},{"vulnId":"V-274714","ruleId":"SV-274714r1143751_rule","severity":"medium","ruleTitle":"The API must use parameterized queries.","description":"A common vulnerability of applications is unpredictable behavior when invalid inputs are received. This requirement guards against adverse or unintended system behavior caused by invalid inputs, where information system responses to the invalid input may be disruptive or cause the system to fail into an unsafe state.\n\nThe behavior will be derived from the organizational and system requirements and includes, but is not limited to, notification of the appropriate personnel, creating an audit record, and rejecting invalid input.","checkContent":"Review the API's source code or backend database interaction layer.\n\nIdentify all database queries constructed using user-supplied input.\n\nVerify that parameterized queries (also known as prepared statements) are used instead of dynamically constructed SQL strings with input concatenation.\n\nConfirm that query parameters are bound using the appropriate method for the language or database framework (e.g., ?, named parameters, or bind variables).\n\nIf any queries use string concatenation or interpolation of user input without parameterization, this is a finding.","fixText":"Follow best practice when accepting user input and verify all input is validated before the API processes the input.\n\nRemediate identified vulnerabilities and obtain documented risk acceptance for those issues that cannot be remediated immediately.","ccis":["CCI-002754"]},{"vulnId":"V-274715","ruleId":"SV-274715r1143753_rule","severity":"medium","ruleTitle":"The API must provide input validation.","description":"A common vulnerability of applications is unpredictable behavior when invalid inputs are received. This requirement guards against adverse or unintended system behavior caused by invalid inputs, where information system responses to the invalid input may be disruptive or cause the system to fail into an unsafe state.\n\nThe behavior will be derived from the organizational and system requirements and includes, but is not limited to, notification of the appropriate personnel, creating an audit record, and rejecting invalid input.","checkContent":"Verify the API provides input validation.\n\nReview the API documentation and interview the API administrator.\nReview the API's input handling mechanisms at all exposed endpoints.\n\nIdentify all points where user input is accepted, including query parameters, headers, body content, and path variables.\n\nVerify that input validation is implemented to enforce expected formats, data types, ranges, and lengths.\n\nEnsure validation occurs on the server side, regardless of any client-side checks.\n\nCheck for validation against known-safe patterns or whitelists (e.g., regex, enumerated values) and proper rejection of malformed or unexpected input.\n\nIf input validation is missing, insufficient, or only enforced on the client side, this is a finding.is is a finding.","fixText":"Follow best practice when accepting user input and verify all input is validated before the API processes the input.\n\nRemediate identified vulnerabilities and obtain documented risk acceptance for those issues that cannot be remediated immediately.","ccis":["CCI-002754"]},{"vulnId":"V-274723","ruleId":"SV-274723r1143761_rule","severity":"medium","ruleTitle":"The API must authenticate remote commands.","description":"Authentication safeguards for remote commands help to ensure that information systems accept and execute, in the order intended, only authorized commands and reject unauthorized commands. \n\nCryptographic mechanisms can be employed, for example, to authenticate remote commands. Safeguards include, at a minimum, FIPS-compliant cryptographic hash.\n\nStandard API authentication protocols provide this protection (e.g., Oauth 2.0, JWT).","checkContent":"Verify the API authenticates remote commands.\n\nIf the API does not authenticate remote commands, this is a finding.","fixText":"Build or configure the API to authenticate remote commands.","ccis":["CCI-003747"]},{"vulnId":"V-274767","ruleId":"SV-274767r1143805_rule","severity":"medium","ruleTitle":"The API must encode outputs.","description":"Output encoding ensures data sent from an API is properly formatted and does not cause unintended effects on the receiving end. \n\nRequiring an API to encode its outputs is a security measure to prevent Cross-Site Scripting (XSS), HTTP Response Splitting, and Log Injection vulnerabilities. \n\nWithout proper encoding, an attacker could inject malicious scripts into API responses, which could be executed when displayed in a web application, leading to XSS attacks. \nImproperly encoded responses could allow attackers to manipulate HTTP headers, causing response splitting that may facilitate cache poisoning or session fixation. \n\nUnencoded user input in logs could introduce log injection issues, obscuring attack traces or triggering unintended system behavior. \n\nEncoding output ensures special characters are safely represented, preventing unintended execution or injection attacks.","checkContent":"Verify the API encodes outputs.\n\nIf the API does not encode outputs, this is a finding.","fixText":"Build or configure the API to encode outputs.","ccis":["CCI-000366"]},{"vulnId":"V-274768","ruleId":"SV-274768r1143806_rule","severity":"medium","ruleTitle":"The API must use a static type of system.","description":"By enforcing strict type checks at compile time, a static type of system ensures that data passed between functions or components is validated against predefined types, reducing the likelihood of unexpected behavior or exploitation. This helps prevent common issues such as SQL injection, buffer overflows, and type-related vulnerabilities, as developers must explicitly define and validate the expected data types. It also improves code clarity, maintainability, and reliability, making it easier to identify and fix security flaws before deployment.","checkContent":"Verify the API is using a static type system.\n\n1. Check the source code for the use of strongly typed languages such as TypeScript, Java, C#, or Go, which enforce type definitions at compile time. \n\n2. Look for explicit type annotations in function signatures, variables, and data structures.\n\n3. Review the project's dependencies to see if type-checking tools or frameworks (e.g., TypeScript for JavaScript, MyPy for Python) are used. \n\n4. Check for the presence of static type checking in the build or compilation process, which ensures type correctness before runtime.\n\nIf the API is not a static type system, this is a finding.","fixText":"Redesign the API to use a static type of system.","ccis":["CCI-000366"]},{"vulnId":"V-274769","ruleId":"SV-274769r1143807_rule","severity":"medium","ruleTitle":"The API must use Web Application Firewall (WAF).","description":"The API must be protected by a Web Application Firewall (WAF) or an API Gateway that monitors and filters incoming and outgoing traffic to prevent injection attacks, ensuring malicious inputs are detected and blocked.","checkContent":"Verify the API is configured to use a WAF or API Gateway to manage traffic.\n\nIf the API is not configured to use a WAF or API Gateway in accordance with organization-defined security policies, this is a finding.","fixText":"Build or configure the API to use a WAF or API Gateway to manage traffic.","ccis":["CCI-000366"]},{"vulnId":"V-274783","ruleId":"SV-274783r1143932_rule","severity":"medium","ruleTitle":"The API must use a FIPS-validated cryptographic module to provision digital signatures for tokens.","description":"FIPS 140-2/140-3 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2/140-3 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2/140-3 standard. \n\nThe cryptographic module used must have at least one validated digital signature function. This validated hash algorithm must be used to generate digital signatures for all cryptographic security function within the product being evaluated.","checkContent":"Verify the API must use a FIPS-validated cryptographic module to provision digital signatures for tokens.\n\nAuthentication to microservices: APIs that have access to sensitive data must not be done simply by using API keys. Access to such APIs must require authentication tokens that have either been digitally signed (e.g., client credentials grant) or verified with an authoritative source. \n\nServices may require either single-use tokens or short-lived tokens (tokens that expire after a short time period) to limit the damage a compromised token can cause.\n\nIf the API does not use a FIPS validated cryptographic module to provision signatures for tokens, this is a finding.","fixText":"Build or configure the API to utilize a FIPS-validated cryptographic module to provision digital signatures.","ccis":["CCI-002450"]},{"vulnId":"V-274785","ruleId":"SV-274785r1143921_rule","severity":"medium","ruleTitle":"API services identified within the system as unnecessary and/or nonsecure must be disabled.","description":"It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary APIs are often overlooked and therefore, may remain unsecured. They increase the risk to the platform by providing additional attack vectors.\n\nAPIs are capable of providing a variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations (e.g., key missions, functions). \n\nExamples of nonessential capabilities include, but are not limited to, enabling application features and functions that are not intended to be used programmatically, such as exposing user self-registration.","checkContent":"Verify API services identified within the system as unnecessary and/or nonsecure are disabled. \n\nReview the API documentation and configuration.\n\nInterview the API administrator.\n\nIdentify the services, network ports, and protocols used by the API.\n\nUsing a combination of relevant OS commands and API configuration utilities, identify the services and TCP/IP port numbers the API is configured to use and is using.\n\nReview the Ports, Protocols, and Services Management (PPSM) Category Assurance List (CAL) at https://cyber.mil/ppsm/cal/.\n\nVerify the ports used by the API are approved by the PPSM CAL.\n\nIf the ports and services are not approved by the PPSM CAL, this is a finding.","fixText":"Build or configure the API to use necessary and secure services and ports approved by the PPSM CAL.","ccis":["CCI-000382"]},{"vulnId":"V-274830","ruleId":"SV-274830r1143869_rule","severity":"medium","ruleTitle":"The API must provide protected storage for API keys.","description":"API key exposure introduces security vulnerabilities to hosted applications. \n\nStore API keys securely, avoiding plaintext storage.\n\nAvoid plain text storage within application code or application source trees.","checkContent":"Verify the API is configured to provide protected storage for API keys, ensuring they are encrypted at rest using cryptographic mechanisms that comply with NIST-approved algorithms and key management standards (e.g., AES-256, FIPS 140-3 validated modules). Protected storage must prevent unauthorized access, tampering, or disclosure of keys, and must enforce access controls consistent with the principle of least privilege. This includes storing keys in secure vaults, hardware security modules (HSMs), or encrypted databases.\n\nIf the API is not configured to provide protected storage for API keys, this is a finding.","fixText":"Build or configure the API to provide protected storage using cryptographic mechanisms that comply with NIST-approved algorithms and key management standards (e.g., AES-256, FIPS 140-3 validated modules) for API keys.","ccis":["CCI-004910"]},{"vulnId":"V-274835","ruleId":"SV-274835r1143875_rule","severity":"medium","ruleTitle":"API must use a circuit breaker pattern to handle failures and timeouts.","description":"A circuit breaker pattern is essential in APIs to prevent cascading failures and improve system resilience. It monitors API calls and temporarily blocks requests when failures reach a threshold, allowing the system to recover before retrying.","checkContent":"Verify the API uses a circuit breaker pattern to handle failures and timeouts.\n\nReview the API documentation or the system's architecture documentation. The pattern might be explicitly mentioned as part of the API's design to handle failures and timeouts.\n\nIf a circuit breaker pattern is not being used, this a finding.","fixText":"Configure the API to use a circuit breaker pattern to handle failures and timeouts.","ccis":["CCI-004992"]},{"vulnId":"V-274839","ruleId":"SV-274839r1143880_rule","severity":"medium","ruleTitle":"Cryptographic keys that protect access tokens must be protected.","description":"Cryptographic keys are used to sign and verify access tokens, ensuring they have not been tampered with and that the user or service presenting the token is legitimate. If these keys are not securely managed, attackers could generate fraudulent tokens, bypass security controls, and gain unauthorized access to sensitive data or services. The API must protect these keys from disclosure or misuse, employing best practices such as key rotation, secure storage, and limiting access to only trusted entities. This minimizes the risk of key compromise, ensures tokens remain valid and trustworthy, and helps maintain the confidentiality and integrity of the authentication system.\n\nBy securing the cryptographic keys, the API mitigates the potential for security breaches and upholds a strong defense against various attack vectors.","checkContent":"To check if cryptographic keys that protect access tokens are properly protected in an API:\n\n1. Verify a proper key management system (KMS) is in place to generate, store, and rotate cryptographic keys. \n\n2. Verify that keys are generated and stored using best practices, ensuring they are never exposed in plaintext.\n\n3. Verify keys are stored securely.\n\n4. Verify keys are not hardcoded in application code or exposed in configuration files.\n\n5. Review who and what services have access to the cryptographic keys. Verify only authorized users or services (e.g., API services) have access to them.\n\n6. Verify key rotation procedures are in place, and cryptographic keys are rotated regularly to mitigate the risk of key compromise.\n\n7. Confirm that any access to or usage of cryptographic keys is logged and auditable. This should include who accessed the key, when, and for what purpose.\n\n8. Review the API's documentation to ensure that cryptographic keys are managed and protected according to security guidelines (e.g., NIST, FIPS).\n\nIf cryptographic keys are not properly protected, this is a finding.","fixText":"Build or configure the API to properly protect cryptographic keys that protect access tokens.","ccis":["CCI-005156","CCI-000366"]},{"vulnId":"V-274840","ruleId":"SV-274840r1143882_rule","severity":"medium","ruleTitle":"The API must protect the private keys used to sign assertions and tokens.","description":"Private keys are used to sign tokens and assertions, which verify the identity and permissions of users or systems requesting access. If these keys are compromised, attackers could generate fraudulent tokens or assertions, granting unauthorized access to sensitive resources and potentially causing significant damage to both the system and its users. \n\nThe level of protection required for these private keys depends on the sensitivity of the information and the potential impact of a security breach. By ensuring private keys are properly secured through strong encryption, access controls, and key management, the API can prevent unauthorized access, safeguard the integrity of the authentication process, and minimize the risk of severe consequences from key compromise.","checkContent":"To check if the API protects the private keys used to sign assertions and tokens:\n\nVerify private keys used for signing tokens and assertions are stored securely. These keys must not be hard coded in the codebase or stored in plaintext files.\n\nVerify private keys are stored in a secure location such as a hardware security module (HSM) or key management service (KMS), which provides encryption and access control.\n\nVerify only authorized personnel or systems can access the keys. Review filesystem permissions.\n\nVerify that the private keys are encrypted both at rest and in transit. If using cloud-based key management systems, ensure that encryption is enabled by default.\n\nVerify private keys are only used for their intended purpose—signing tokens and assertions. \n\nAudit the system to ensure that keys are only accessible during token generation or signing processes and not left accessible longer than needed.\n\nConfirm that there is a key rotation policy in place for the private keys used to sign tokens and assertions. These keys should be rotated regularly to reduce the risk of compromise.\n\nImplement monitoring and logging mechanisms to audit any access to, or use of, private keys. Logs must capture who accessed the key, when, and for what purpose.\n\nReview the API's or key management system's documentation to confirm private key protection practices align with industry standards, such as NIST guidelines and FIPS compliance.\n\nIf the API is not protecting private keys, this is a finding.","fixText":"Build or configure the API to properly protect private keys used to sign assertions and tokens.","ccis":["CCI-005157","CCI-000366"]},{"vulnId":"V-274841","ruleId":"SV-274841r1143884_rule","severity":"medium","ruleTitle":"Generating assertions must be restricted.","description":"An API may be required to generate assertions when it plays a role in authentication, authorization, or secure data exchange. In protocols like SAML or OpenID Connect, assertions are essential because they serve as trusted claims about a user's identity, permissions, or session status. These assertions, often in the form of tokens like SAML assertions or JWTs, allow different systems to communicate securely and trust the integrity of the transmitted information. By generating assertions, an API ensures that only authenticated users can access protected resources, and that the data exchanged is verifiable and tamper-proof.","checkContent":"Review the API's authentication and authorization mechanisms. Ensure that the assertions are generated using the correct identity source's identity provider (IdP). \n\nVerify the API adheres to the defined authentication standards to ensure only authenticated and authorized entities can generate assertions. \n\nCheck the assertions include necessary identity information (e.g., user ID, roles, and claims) and are signed or encrypted. \n\nVerify the generation process is compliant with any guidelines regarding assertion lifetime, scope, and audience. \n\nReview system logs to confirm the API is correctly implementing the authentication policies and generating assertions only after successful identity verification.\n\nConsult the organization's identity management documentation and compare it to the API's implementation to ensure full alignment with the defined policies.\n\nIf the API is not generating assertions in accordance with organization-defined identification and authentication policy, this is a finding.","fixText":"Build or configure the API to generate assertions in accordance with organization-defined identification and authentication policy.","ccis":["CCI-005158","CCI-000366"]},{"vulnId":"V-274842","ruleId":"SV-274842r1143886_rule","severity":"medium","ruleTitle":"The API must issue assertions in accordance with organization-defined identification and authentication policy.","description":"An API must issue assertions when it acts as an identity provider or plays a role in secure authentication and authorization processes. Assertions are structured, verifiable claims—such as user identity, roles, or permissions—that allow other systems to trust the information being exchanged. In protocols like SAML, OAuth, or OpenID Connect, issuing assertions (e.g., SAML assertions or JWTs) enables the API to confirm that a user has been authenticated and is authorized to access specific resources. This is essential for enabling secure communication across systems, enforcing access control, and ensuring that sensitive operations are only performed by verified users or applications. Without issuing assertions, the API cannot provide the necessary trust and security guarantees required in modern distributed systems.","checkContent":"Reviewing the API's authentication and authorization mechanisms. Verify the assertions are issued using the correct identity source's identity provider (IdP). \n\nVerify the API adheres to the defined authentication standards to ensure that only authenticated and authorized entities can issue assertions. \n\nCheck the assertions include necessary identity information (e.g., user ID, roles, and claims) and are signed or encrypted. \n\nValidate the issued process is compliant with any guidelines regarding assertion lifetime, scope, and audience. \n\nCheck that the API enforces rules for assertion expiration, audience restrictions, and security measures like encryption or digital signatures, ensuring assertions cannot be tampered with or misused.\n\nConsult the organization's identity management documentation and compare it to the API's implementation to ensure full alignment with the defined policies.\n\nIf the API is not issuing assertions in accordance with organization-defined identification and authentication policy, this is a finding.","fixText":"Build or configure the API to issue assertions in accordance with organization-defined identification and authentication policy.","ccis":["CCI-005159","CCI-000366"]},{"vulnId":"V-274843","ruleId":"SV-274843r1143888_rule","severity":"medium","ruleTitle":"The API must refresh assertions in accordance with organization-defined identification and authentication policy.","description":"An API must refresh assertions to maintain secure, uninterrupted access while ensuring that authentication and authorization remain valid over time. Assertions, such as JWTs or SAML tokens, often have expiration times to reduce the risk of misuse if compromised. By implementing a mechanism to refresh these assertions—typically using refresh tokens or re-authentication flows—the API can issue new assertions without requiring the user to log in repeatedly. This not only enhances user experience by supporting seamless sessions but also strengthens security by periodically re-evaluating the user's credentials and access rights. Refreshing assertions ensures that access remains both valid and aligned with any changes in user roles, permissions, or session status.","checkContent":"Check if the API refreshes assertions in accordance with the organization-defined identification and authentication policy.\n\nReview the API's handling of assertion expiration and renewal. \n\nEnsure the API follows the organization's defined policies for assertion lifetime, including the duration before assertions need to be refreshed or reissued. \n\nCheck if the API requires reauthentication or uses a secure refresh mechanism, such as refresh tokens or secure revalidation processes, to generate new assertions when they expire.\n\nVerify the process for refreshing assertions maintains security standards, including proper encryption, secure token storage, and validation of the refreshed assertions before they are issued. \n\nReview the API's implementation to confirm it adheres to the organization's authentication policy for refreshing, ensuring that refreshed assertions include up-to-date identity information and relevant claims, and that they are properly scoped. \n\nTest the API by requesting new assertions after expiration and examining whether they are refreshed securely and according to policy, ensuring compliance with the organization's standards for identity management and authentication.\n\nIf the API does not refresh assertions in accordance with organization-defined identification and authentication policy, this is a finding.","fixText":"Build or configure  the API to refresh assertions in accordance with organization-defined identification and authentication policy.","ccis":["CCI-005160","CCI-000366"]},{"vulnId":"V-274844","ruleId":"SV-274844r1143890_rule","severity":"medium","ruleTitle":"The API must revoke assertions in accordance with organization-defined identification and authentication policy.","description":"An API must revoke assertions to immediately terminate access when a user's credentials are compromised, their permissions change, or their session is no longer valid. Assertions like JWTs or SAML tokens grant access to protected resources, and if not actively revoked, can be exploited even after a user's access is removed. By supporting assertion revocation, such as maintaining a token blacklist or using short-lived tokens with active invalidation, the API enhances security by ensuring outdated or potentially dangerous assertions cannot be reused. This is critical in scenarios involving logout, credential theft, or administrative role changes, where continued access could lead to unauthorized data exposure or system compromise.","checkContent":"Verify that the API has an implemented and functional revocation mechanism. This could involve endpoints or methods that allow for the invalidation of assertions, such as a revocation list or a central system for tracking revoked assertions.\n\nSimulate the revocation of assertions by either manually revoking access or simulating scenarios that trigger revocation (e.g., a user's session being terminated, access being revoked due to a policy violation). Ensure the API properly invalidates the assertions and prevents further access with the revoked assertions.\n\nReview Logging and Auditing of Revocation Events:\nConfirm that the API logs revocation events, capturing key details such as who initiated the revocation, when it occurred, and why it was revoked. \n\nAfter revocation, test that any attempt to use the revoked assertion is properly rejected by the API. The API should deny access if the assertion has been invalidated, ensuring no further use is possible.\n\nRefer to the API's documentation to confirm that revocation processes are correctly implemented in line with the organization's defined policies for identity management and authentication.\n\nIf the API does not revoke assertions in accordance with organization-defined identification and authentication policy, this is a finding.","fixText":"Build or configure the API to revoke assertions in accordance with organization-defined identification and authentication policy.","ccis":["CCI-005161","CCI-000366"]},{"vulnId":"V-274845","ruleId":"SV-274845r1143892_rule","severity":"medium","ruleTitle":"The API must time-restrict assertions in accordance with organization-defined identification and authentication policy.","description":"An API must time-restrict assertions to minimize security risks and ensure access to protected resources is granted only within a valid and controlled timeframe. Assertions, such as JWTs or SAML tokens, typically include expiration timestamps that limit how long they are valid. This prevents long-term misuse in case a token is leaked or intercepted and helps enforce periodic re-authentication or authorization checks. By applying time restrictions, the API reduces the window of opportunity for unauthorized access, aligns with best practices in secure session management, and supports compliance with policies that require timely validation of user credentials and permissions.","checkContent":"Reviewing the organization's identification and authentication policy's defined rules for assertion validity duration. This should include the maximum lifespan of assertions, such as the allowed expiration time after issuance.\n\nCheck the API's implementation to ensure it generates assertions with the correct expiration times based on the organization's policy. Assertions must include expiration claims (e.g., exp in JWT tokens), and the API must enforce these time restrictions automatically.\n\nSimulate the use of assertions at different times, including immediately after issuance and near expiration. Ensure the API correctly rejects assertions that have expired or are no longer valid according to the defined time restrictions.\n\nVerify the API is applying time-based policies for issuing or renewing assertions. For example, it should not issue assertions with a duration that exceeds the time limits set by the organization. It should also handle scenarios like late requests that could fall outside the permitted time window.\n\nReview the API logs to verify expiration and time-based events are being properly logged, including when an assertion is created, expired, or rejected due to time constraints. \n\nRefer to the API's documentation to ensure the time restriction policy is implemented correctly and compliant with the organization's defined standards for assertion time management.\n\nIf the API does not time restrict assertions in accordance with organization-defined identification and authentication policy, this is a finding.","fixText":"Build or configure the API to time-restrict assertions in accordance with organization-defined identification and authentication policy.","ccis":["CCI-005162","CCI-000366"]},{"vulnId":"V-274846","ruleId":"SV-274846r1143894_rule","severity":"medium","ruleTitle":"The API must audience-restrict assertions in accordance with organization-defined identification and authentication policy.","description":"An API must audience-restrict assertions to ensure the information or access granted by a token is only usable by its intended recipient. Assertions like JWTs or SAML tokens often include an \"audience\" (aud) claim, which specifies the exact service or API that is authorized to consume the assertion. Without this restriction, a token could be intercepted and used by an unintended or malicious service, potentially leading to unauthorized access or data breaches. By enforcing audience restrictions, the API strengthens its security posture by ensuring assertions cannot be misused outside their intended context.","checkContent":"Review the organization's identification and authentication policy to understand the specific audience restrictions defined, including which entities or systems are allowed to consume the assertions and how audience claims are handled.\n\nCheck the API's implementation to verify assertions include proper audience claims (e.g., aud in JWT tokens). The audience claim must specify which entity or service is permitted to use the assertion, in accordance with the organization's policy.\n\nSimulate the use of assertions by different services or users to verify the API correctly enforces audience restrictions. The API must reject any assertion that is not intended for the current consumer or service, based on the audience claim.\n\nVerify the audience values specified in the assertions align with the organization's policy. \n\nCheck that the API logs events related to audience validation, including successful and failed attempts to access protected resources based on audience restrictions. These logs must be detailed enough to identify when audience-related validation occurs and whether access was granted or denied.\n\nIf the API relies on third-party identity providers (IdPs) or other systems for generating assertions, verify these systems correctly implement audience restriction policies. Test the integration between these systems and the API to verify that audience-restricted assertions are being correctly issued and consumed.\n\nReview the API's documentation to confirm audience restrictions are implemented correctly, and ensure the API is fully compliant with the organization's defined audience control policies.\n\nIf the API does not audience restrict assertions in accordance with organization-defined identification and authentication policy, this is a finding.","fixText":"Build or configure the API to audience-restrict assertions in accordance with organization-defined identification and authentication policy.","ccis":["CCI-005163","CCI-000366"]},{"vulnId":"V-274847","ruleId":"SV-274847r1143896_rule","severity":"medium","ruleTitle":"The API must generate access tokens in accordance with organization-defined identification and authentication policy.","description":"An API must generate access tokens to securely manage authentication and authorization directly within the application. Access tokens, such as JWTs or opaque tokens, serve as verifiable credentials that clients present when accessing protected resources. \n\nWithout an API gateway to handle token issuance and validation, the API itself becomes responsible for ensuring only authenticated and authorized users can interact with it. By generating access tokens, the API enables secure, stateless sessions, simplifies permission checks, and reduces the need to validate user credentials on every request. This is essential for protecting sensitive data, enforcing access controls, and enabling scalable, secure communication in distributed systems.","checkContent":"Review the organization's identification and authentication policy to understand requirements for access token generation, including allowed token types, token claims, encryption/signature requirements, and conditions under which tokens may be issued.\n\nExamine the API or authentication server code/configuration responsible for token issuance. Verify it enforces authentication of clients or users before issuing a token and that it includes required attributes (e.g., subject ID, roles, scopes) based on the policy.\n\nGenerate tokens using valid authentication requests and inspect their structure and contents. Confirm the issued tokens include the proper claims, are correctly signed/encrypted, and match the formatting (e.g., JWT) required by policy.\n\nAttempt to obtain tokens under various conditions, including successful and failed login attempts, and with different scopes or resource requests. Confirm tokens are only issued in compliance with authentication success and policy-based restrictions.\n\nIf the API uses an identity provider (IdP) or API Gateway for token generation, review those configurations to verify they enforce organizational policies during token issuance.\n\nIf the API does not generate access tokens in accordance with organization-defined identification and authentication policy, this is a finding.","fixText":"Build or configure the API to generate access tokens in accordance with organization-defined identification and authentication policy.","ccis":["CCI-005164","CCI-000366"]},{"vulnId":"V-274848","ruleId":"SV-274848r1143898_rule","severity":"medium","ruleTitle":"The API must issue access tokens in accordance with organization-defined identification and authentication policy.","description":"An API must issue access tokens to independently handle authentication and authorization for securing access to its resources. By issuing access tokens, the API ensures only authenticated users with valid permissions can interact with the system. \n\nWithout an API gateway to centralize this process, the API itself must authenticate users, generate tokens (like JWTs), and validate those tokens on each request. This approach enables the API to maintain control over access policies, provides a stateless way of handling user sessions, and ensures sensitive data is protected by verifying the user's identity and access rights for every request. Issuing tokens directly also simplifies integration with other services and supports scalable, distributed architectures.","checkContent":"Review the code, configuration or identity provider responsible for issuing tokens. Verify it enforces the required authentication procedures and that tokens are not issued without proper user or client validation.\n\nPerform a valid authentication flow to receive an access token. Examine the token to ensure it includes required fields like sub (subject), aud (audience), exp (expiration), iat (issued at), and any scopes or roles defined by policy.\n\nAttempt to obtain tokens using invalid credentials, insufficient authentication methods, or unauthorized client requests. Confirm the API does not issue access tokens in these cases, in alignment with the policy.\n\nCheck that the token is signed or encrypted using the approved cryptographic algorithms. Ensure keys are securely managed and that tokens cannot be tampered with.\n\nVerify that the token's expiration time matches what the policy defines. Ensure short-lived tokens are used where required, especially for sensitive or high-risk data access.\n\nReview API or identity provider documentation to confirm whether token issuance behavior aligns with organizational requirements.\n\nIf any misconfigurations are identified, this is a finding.","fixText":"Build or configure the API to issue access tokens in accordance with organization-defined identification and authentication policy.","ccis":["CCI-005165","CCI-000366"]},{"vulnId":"V-274849","ruleId":"SV-274849r1143900_rule","severity":"medium","ruleTitle":"The API must refresh access tokens in accordance with organization-defined identification and authentication policy.","description":"An API must refresh access tokens to maintain secure, uninterrupted access while minimizing the risk of token misuse or expiration. Access tokens typically have a limited lifespan and refreshing them allows users to maintain active sessions without needing to re-authenticate. \n\nIf the API is not relying on an API Gateway for token management, it becomes responsible for issuing and refreshing tokens directly, ensuring that users can continue to interact with the API seamlessly, while also enforcing up-to-date authentication. By implementing token refresh, the API can validate the user's ongoing permissions, reduce the risk of session hijacking, and prevent users from being locked out due to expired tokens, all while maintaining a stateless, scalable approach to security.","checkContent":"Review the API or authorization server's refresh token endpoint logic. Confirm that it validates the refresh token, checks expiration, and enforces any associated conditions like device binding or client verification.\n\nSimulate valid and invalid refresh scenarios. Use an active refresh token to obtain a new access token and confirm that the new token includes required claims, is properly signed, and has an appropriate expiration time. \n\nVerify the refresh process enforces client authentication, restricts token reuse (e.g., one-time-use refresh tokens if required), and aligns with the cryptographic and authentication strength.\n\nExamine the newly issued access tokens to verify they include correct fields like exp, iat, aud, and scope, and that their validity periods are consistent with the organization's guidelines.\n\nConsult the API or identity provider documentation and configuration to verify refresh behavior is implemented in accordance with the defined organizational standards.\n\nIf any misconfigurations are identified, this is a finding.","fixText":"Build or configure the API to refresh access tokens in accordance with organization-defined identification and authentication policy.","ccis":["CCI-005166","CCI-000366"]},{"vulnId":"V-274850","ruleId":"SV-274850r1143901_rule","severity":"medium","ruleTitle":"The API must revoke access tokens in accordance with organization-defined identification and authentication policy.","description":"An API must revoke access tokens to immediately terminate access when a user's session or permissions are no longer valid or if there is a security breach, such as token theft. \n\nWithout an API gateway managing token revocation, the API itself becomes responsible for handling scenarios where access needs to be revoked, such as when a user logs out, their credentials are compromised, or their role changes. By revoking access tokens, the API ensures that even if a token is intercepted or misused, it cannot be used beyond its intended lifespan, thereby enhancing security. This ability to revoke tokens also helps protect sensitive data and ensures that unauthorized users cannot access protected resources, even if they possess a valid token.","checkContent":"Review the API or identity provider implementation to verify there is a token revocation mechanism in place (e.g., an OAuth 2.0 /revoke endpoint). Confirm it adheres to the policy by requiring appropriate authentication and validating the token before revocation.\n\nUse an issued access token to perform API calls, then invoke the revocation process. After revocation, attempt to use the same token again. The API should reject the request, demonstrating that the token is no longer valid.\n\nIf tokens are cached or used across distributed systems, verify revocation is promptly propagated and enforced across all relevant services in accordance with policy requirements.\n\nIf the system uses a token store or blacklist, verify revoked tokens are added to it and that the API checks against it before granting access.\n\nConsult API or identity provider documentation to confirm support for revocation features and verify they are configured to align with organizational policies.\n\nIf any misconfigurations are identified, this is a finding.","fixText":"Build or configure the API to revoke access tokens in accordance with organization-defined identification and authentication policy.","ccis":["CCI-005167","CCI-000366"]},{"vulnId":"V-274851","ruleId":"SV-274851r1143903_rule","severity":"medium","ruleTitle":"The API must time-restrict access tokens in accordance with organization-defined identification and authentication policy.","description":"An API must time-restrict access tokens to enhance security by limiting the window of opportunity for unauthorized access. Access tokens typically have an expiration time to reduce the risks associated with token theft or misuse. \n\nWithout an API gateway to handle token expiration, the API itself must enforce token validity by ensuring tokens are only accepted for a limited period. This will mitigate the impact of a compromised token by preventing it from being used indefinitely. Time-restricting tokens also ensures that the API regularly re-validates user sessions, aligns with best security practices, and forces users to re-authenticate after a certain period, thereby reducing the chance of long-term unauthorized access.","checkContent":"Examine the organization's identification and authentication policy required lifespan of access tokens. This includes default expiration times, any conditions for shorter or longer durations, and rules for different user roles or access levels.\n\nReview the code or configuration responsible for generating access tokens to ensure it sets the exp (expiration) and iat (issued at) claims according to policy. Confirm that tokens are not issued with excessively long lifetimes unless explicitly allowed.\n\nAuthenticate and obtain access tokens under various scenarios (e.g., user login, system-to-system access). Decode the tokens (e.g., if JWT) and check the exp and iat fields to verify the validity period aligns with the organization's defined rules.\n\nWait until a token expires and attempt to use it with the API. Confirm the API correctly rejects expired tokens with appropriate error responses (e.g., HTTP 401 Unauthorized or 403 Forbidden).\n\nDetermine whether the API adjusts token lifespans based on risk factors, user roles, or sensitivity of requested resources. This must also comply with the organizational policy.\n\nEnsure the API validates the exp claim on each request and denies access to expired tokens.\n\nLook into API or identity provider configuration files to confirm that token timeout values match policy-defined thresholds.\n\nIf any misconfigurations are identified, this is a finding.","fixText":"Build or configure the API to revoke access tokens in accordance with organization-defined identification and authentication policy.","ccis":["CCI-005168","CCI-000366"]}]}