Application Programming Interface (API) Security Requirements Guide V1R1

b

The API must encrypt data in transit.

AC-17 - Medium - CCI-000068 - V-274497 - SV-274497r1142303_rule

RMF Control

AC-17

Severity

M

CCI

CCI-000068

Version

SRG-APP-000014-API-000020

Vuln IDs

V-274497

Rule IDs

SV-274497r1142303_rule

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.

Checks: C-78598r1142301_chk

API must verify sensitive tokens are transmitted over secure channels using HTTPS. This includes both internal and user-specific tokens. If data being transmitted between the client and server is not using HTTPS, this is a finding.

Fix: F-78503r1142302_fix

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.

b

The API must be configured to use approved authorizations for access control.

AC-3 - Medium - CCI-000213 - V-274507 - SV-274507r1143927_rule

RMF Control

AC-3

Severity

M

CCI

CCI-000213

Version

SRG-APP-000033-API-000070

Vuln IDs

V-274507

Rule IDs

SV-274507r1143927_rule

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. Access 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. This requirement is applicable to access control enforcement applications (e.g., authentication servers) and other applications that perform information and system access control functions. Methods include: - Basic Authentication (not recommended). - API Key Authentication. - TLS Encryption. - OAuth 2.0. - JWT-Based Authentication. - OpenID Connect (OIDC).

Checks: C-78608r1143926_chk

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. Ensure 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. Review system documentation, API gateway configurations, and authorization policies to verify that access control decisions are: - Based on real-time evaluation of user identity, role, device posture, and other attributes. - Applied consistently across all API endpoints. - Logged for auditing and accountability. If 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.

Fix: F-78513r1143421_fix

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). Update system documentation to reflect the authorization strategy and verify integration with access management and logging systems to meet Zero Trust Capability requirements.

b

The API must enable monitoring and alerts.

AU-12 - Medium - CCI-000169 - V-274517 - SV-274517r1143512_rule

RMF Control

AU-12

Severity

M

CCI

CCI-000169

Version

SRG-APP-000089-API-000120

Vuln IDs

V-274517

Rule IDs

SV-274517r1143512_rule

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. Audit 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. DOD has defined the list of events for which the application will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (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 (iii) All account creation, modification, disabling, and termination actions.

Checks: C-78618r1143423_chk

Verify the API enables monitoring and alerts. Confirm 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. If 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.

Fix: F-78523r1142362_fix

Build or configure the API to enable monitoring and alerts.

b

The API Gateway must generate audit records when successful/unsuccessful attempts to access privileges occur.

AU-12 - Medium - CCI-000172 - V-274519 - SV-274519r1143513_rule

RMF Control

AU-12

Severity

M

CCI

CCI-000172

Version

SRG-APP-000091-API-001725

Vuln IDs

V-274519

Rule IDs

SV-274519r1143513_rule

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.

Checks: C-78620r1143425_chk

If an API Gateway is not in use, this is Not Applicable. 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). Perform various test cases to simulate both successful and unsuccessful access. After 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. Cross-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. If the API Gateway does not generate audit records when successful/unsuccessful attempts to access privileges occur, this is a finding.

Fix: F-78525r1142368_fix

Build or configure the API Gateway to enable logging successful/unsuccessful attempts to access privileges.

b

The API must generate audit records when successful/unsuccessful attempts to access privileges occur.

AU-12 - Medium - CCI-000172 - V-274520 - SV-274520r1143514_rule

RMF Control

AU-12

Severity

M

CCI

CCI-000172

Version

SRG-APP-000091-API-001730

Vuln IDs

V-274520

Rule IDs

SV-274520r1143514_rule

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. Unsuccessful 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.

Checks: C-78621r1143427_chk

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). Perform various test cases to simulate both successful and unsuccessful access. After 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. Cross-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. If the API does not generate audit records when successful/unsuccessful attempts to access privileges occur, this is a finding.

Fix: F-78526r1142371_fix

Build or configure the API to enable logging successful/unsuccessful attempts to access privileges.

b

The API Gateway must generate audit records of what type of events occurred.

AU-3 - Medium - CCI-000130 - V-274522 - SV-274522r1143515_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001735

Vuln IDs

V-274522

Rule IDs

SV-274522r1143515_rule

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.

Checks: C-78623r1143429_chk

If an API Gateway is not in use, this is Not Applicable. Verify the API Gateway generates audit records of what type of events occurred. 1. 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. 2. Make a valid API request and verify successful events are logged. 3. Simulate system errors by causing the API to fail under specific conditions (e.g., database unavailability, timeout errors, internal exceptions). 4. 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. 5. Inspect the log entries for the following: - Event Type: The event’s description or category (e.g., authentication attempt, data access, system error). If the API Gateway does not generate audit records for the type of event, this is a finding.

Fix: F-78528r1142377_fix

Build or configure the API Gateway to audit what type of events occurred.

b

The API must monitor the usage of API keys to detect any anomalies.

AU-3 - Medium - CCI-000130 - V-274523 - SV-274523r1143516_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001740

Vuln IDs

V-274523

Rule IDs

SV-274523r1143516_rule

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. API 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. Anomalies 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. Monitoring also helps enforce usage limits and detect overuse or abuse of API resources, which could impact system performance.

Checks: C-78624r1143431_chk

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. If API key usage is not being monitored for anomalies, this is a finding.

Fix: F-78529r1143432_fix

Build or configure the API to monitor API key usage and flag anomalies: Enable Logging: Log all API key usage, including timestamps, IP addresses, endpoints accessed, and request rates. Define Normal Behavior: Establish a baseline for expected usage patterns (e.g., typical request rate, endpoints used, geographic regions). Set Thresholds: Configure thresholds for detecting anomalies such as excessive requests, access to unusual resources, or use from unexpected locations. Integrate Monitoring Tools: Use API management or SIEM tools to analyze logs and trigger alerts on anomalous activity. Automate Alerts: Set up real-time notifications or automated actions (e.g., temporary blocking) when anomalies are detected.

b

The API must generate audit records of what type of events occurred.

AU-3 - Medium - CCI-000130 - V-274524 - SV-274524r1143517_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001745

Vuln IDs

V-274524

Rule IDs

SV-274524r1143517_rule

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. Audit 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. Associating 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. Monitor the usage of API keys to detect any anomalies.

Checks: C-78625r1143434_chk

Verify the API generates audit records of what type of events occurred. 1. 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. 2. Make a valid API request and verify successful events are logged. 3. Simulate system errors under specific conditions (e.g., database unavailability, timeout errors, internal exceptions). 4. 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. 5. Inspect the log entries for the following: - Event Type: Look for the event’s description or category (e.g., authentication attempt, data access, system error). If the API does not generate audit records for the type of event, this is a finding.

Fix: F-78530r1142383_fix

Build or configure the API to audit what type of events occurred.

b

The API must audit rate-limiting events.

AU-3 - Medium - CCI-000130 - V-274525 - SV-274525r1143929_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001750

Vuln IDs

V-274525

Rule IDs

SV-274525r1143929_rule

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.

Checks: C-78626r1143928_chk

Verify the API audits rate-limiting events. 1. 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). 2. Verify rate-limiting events are configured to be logged. This includes events where a user exceeds their allowed request rate, triggering rate-limiting actions. The API's audit or access log entries should: - Indicate when a rate limit was exceeded. - Include details about the API key or user who exceeded the limit. - Provide the rate-limiting threshold (e.g., "rate limit exceeded: 1,000 requests per hour"). - Mention the specific API endpoint that was accessed. 3. Review the organization's security policies to ensure rate-limiting events are properly audited as per requirements. If the API is not auditing rate limiting events, this is a finding.

Fix: F-78531r1142386_fix

Build or configure the API Gateway to enforce rate limits and log these events, including the thresholds for triggering rate limiting.

b

The API Gateway must audit rate limiting events.

AU-3 - Medium - CCI-000130 - V-274526 - SV-274526r1143552_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001755

Vuln IDs

V-274526

Rule IDs

SV-274526r1143552_rule

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.

Checks: C-78627r1143551_chk

If an API Gateway is not in use, this is Not Applicable. 1. 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). 2. Verify rate-limiting events are configured to be logged. This includes events where a user exceeds their allowed request rate, triggering rate-limiting actions. 3. After triggering rate-limiting events, check the API's audit or access logs. Entries should: - Indicate when a rate limit was exceeded. - Include details about the API key or user who exceeded the limit. - Provide the rate-limiting threshold (e.g., "rate limit exceeded: 1000 requests per hour"). - Mention the specific API endpoint that was accessed. 4. 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). 5. 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). 6. Review the organization's security policies to ensure rate-limiting events are properly audited as per requirements. If the API Gateway is not auditing rate limiting events, this is a finding.

Fix: F-78532r1142389_fix

Build or configure the API Gateway to enforce rate limits and log these events, including the thresholds for triggering rate limiting.

b

The API Gateway must audit authentication and authorization information.

AU-3 - Medium - CCI-000130 - V-274527 - SV-274527r1143553_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001760

Vuln IDs

V-274527

Rule IDs

SV-274527r1143553_rule

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.

Checks: C-78628r1143440_chk

If an API Gateway is not in use, this is Not Applicable. Verify the API Gateway audits authentication and authorization information. 1. 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). 2. Verify the logs capture relevant authentication and authorization details. 3. 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). If the API Gateway does not audit authentication and authorization information, this is a finding.

Fix: F-78533r1142392_fix

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).

b

The API must audit authentication and authorization information.

AU-3 - Medium - CCI-000130 - V-274528 - SV-274528r1143554_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001765

Vuln IDs

V-274528

Rule IDs

SV-274528r1143554_rule

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.

Checks: C-78629r1142394_chk

Verify the API generates audit records of what type of events occurred. 1. 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). 2. Verify the logs capture relevant authentication and authorization details. 3. 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). If the API does not audit authentication and authorization information, this is a finding.

Fix: F-78534r1142395_fix

Build or configure the API to log authentication and authorization events, including the appropriate level of detail (e.g., timestamps, user IDs, status codes).

b

The API Gateway must audit exceptions and errors that occur during the processing.

AU-3 - Medium - CCI-000130 - V-274529 - SV-274529r1143555_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001770

Vuln IDs

V-274529

Rule IDs

SV-274529r1143555_rule

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.

Checks: C-78630r1143442_chk

If an API Gateway is not in use, this is Not Applicable. Verify the API Gateway audits exceptions and errors that occur during the processing. 1. Inspect the API Gateway logs to ensure they capture exception and error events, including error codes, messages, and stack traces. 2. Simulate errors (e.g., invalid requests or server failures) and verify these are logged with relevant details like timestamps and error types. 3. Verify the API Gateway is configured to log exceptions and errors with sufficient detail for troubleshooting and analysis. 4. Review the API Gateway documentation support to ensure proper auditing of exceptions and errors is enabled. If the API Gateway does not audit exceptions and errors, this is a finding.

Fix: F-78535r1142398_fix

Build or configure the API Gateway to log errors and exceptions, including the level of detail, such as timestamps, error type, and affected resources.

b

The API must audit exceptions and errors that occur during the processing.

AU-3 - Medium - CCI-000130 - V-274530 - SV-274530r1143557_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001775

Vuln IDs

V-274530

Rule IDs

SV-274530r1143557_rule

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. Audit 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. Associating 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. Monitor the usage of API keys to detect any anomalies.

Checks: C-78631r1143556_chk

Verify the API audits exceptions and errors that occur during the processing. 1. Inspect the API's logs to ensure they capture exception and error events, including error codes, messages, and stack traces. 2. Simulate errors (e.g., invalid requests or server failures) and verify these are logged with relevant details like timestamps and error types. 3. Ensure the API is configured to log exceptions and errors with sufficient detail for troubleshooting and analysis. 4. Review the API's documentation support to ensure proper auditing of exceptions and errors is enabled. If the API does not audit exceptions and errors, this is a finding.

Fix: F-78536r1142401_fix

Build or configure the API to log exceptions and errors with sufficient detail for troubleshooting and analysis.

b

The API Gateway must audit execution time and performance metrics.

AU-3 - Medium - CCI-000130 - V-274531 - SV-274531r1143559_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001780

Vuln IDs

V-274531

Rule IDs

SV-274531r1143559_rule

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. Along 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.

Checks: C-78632r1143558_chk

If an API Gateway is not in use, this is Not Applicable. Verify the API Gateway audits execution time and performance metrics. 1. Inspect the API Gateway's logs to verify they capture performance-related data, such as execution times, request latency, and throughput. 2. Simulate various requests and monitor the execution times, verifying performance metrics are logged for each request or operation. 3. Verify the API Gateway is configured to log execution times and track key performance metrics, including thresholds for alerts. 4. Review the API Gateway's documentation to ensure auditing of execution time and performance metrics is properly configured and operational. If the API Gateway is not auditing execution time and performance metrics, this is a finding.

Fix: F-78537r1142404_fix

Build or configure the API Gateway to log execution times and track key performance metrics, including thresholds for alerts.

b

The API must audit execution time and performance metrics.

AU-3 - Medium - CCI-000130 - V-274532 - SV-274532r1143561_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001785

Vuln IDs

V-274532

Rule IDs

SV-274532r1143561_rule

The API must audit execution time and performance metrics to ensure optimal operation, detect bottlenecks, and maintain a high level of service reliability. Monitoring and logging execution time allows the API to track how long each request takes to process, helping to identify slow endpoints or inefficient processing. By 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. Along 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.

Checks: C-78633r1143560_chk

Verify the API audits execution time and performance metrics. 1. Inspect the API's logs to ensure they capture execution times, request latency, and other performance metrics. 2. Simulate various requests and verify execution time and performance metrics are logged correctly. 3. Verify the API is configured to track and log performance data, including response times and throughput. 4. Review the API's documentation to ensure execution time and performance auditing is enabled. If the API is not auditing execution time and performance metrics, this is a finding.

Fix: F-78538r1142407_fix

Build or configure the API to track and log performance data, including response times and throughput.

b

The API Gateway must audit request and response details (such as method, URL, headers, body, status, etc.).

AU-3 - Medium - CCI-000130 - V-274533 - SV-274533r1143563_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001790

Vuln IDs

V-274533

Rule IDs

SV-274533r1143563_rule

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). Detailed 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.

Checks: C-78634r1143562_chk

If an API Gateway is not in use, this is Not Applicable. Verify the API audits execution time and performance metrics. 1. Inspect the API Gateway's logs to verify they capture details of incoming requests and outgoing responses, including headers, body content, and status codes. 2. Simulate various requests and verify that both request and response details are being logged correctly, including any data passed and the response outcome. 3. 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. 4. Review the API Gateway's documentation to ensure proper auditing of request and response details is enabled. If the API Gateway is not auditing request and response detail, this is a finding.

Fix: F-78539r1142410_fix

Build or configure the API Gateway to log the necessary request and response details such as method, URL, headers, body, status, etc.

b

The API must audit request and response details (such as method, URL, headers, body, status, etc.).

AU-3 - Medium - CCI-000130 - V-274534 - SV-274534r1143565_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

SRG-APP-000095-API-001795

Vuln IDs

V-274534

Rule IDs

SV-274534r1143565_rule

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.

Checks: C-78635r1143564_chk

Verify the API audits request and response details. 1. Inspect the API's logs to verify they capture details of incoming requests and outgoing responses, including headers, body content, and status codes. 2. Simulate various requests and verify that both request and response details are being logged correctly, including any data passed and the response outcome. 3. Verify the API is configured to log the necessary request and response details, such as the type of request, request parameters, and response status. 4. Review the API's documentation to ensure proper auditing of request and response details is enabled. If the API is not auditing request and response detail, this is a finding.

Fix: F-78540r1142413_fix

Build or configure the API to log the necessary request and response details such as method, URL, headers, body, status, etc.

b

All defined API elements must be documented.

AU-3 - Medium - CCI-000133 - V-274537 - SV-274537r1143570_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000133

Version

SRG-APP-000098-API-000145

Vuln IDs

V-274537

Rule IDs

SV-274537r1143570_rule

All defined API elements and their security-relevant configurations must be documented and enforced, ensuring compliance with the organization's approved security baselines. Identifying all API elements that must be logged is essential for security, monitoring, and threat detection. Documenting 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.

Checks: C-78638r1143568_chk

To identify APIs in use: Analyze application code for API calls, URLs, and authentication keys in frontend and backend components. Use network monitoring tools to capture API traffic in real time. Check browser DevTools (Network tab) for active API requests in web applications. Review server and API gateway logs (e.g., AWS CloudWatch, Nginx logs) to track API calls and usage patterns. Inspect configuration files, environment variables, and documentation for references to external or internal APIs. If 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.

Fix: F-78543r1143569_fix

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.

b

API keys must be configured with usage restrictions.

CM-7 - Medium - CCI-000381 - V-274556 - SV-274556r1143589_rule

RMF Control

CM-7

Severity

M

CCI

CCI-000381

Version

SRG-APP-000141-API-000240

Vuln IDs

V-274556

Rule IDs

SV-274556r1143589_rule

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. Restricting 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.

Checks: C-78657r1143451_chk

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.

Fix: F-78562r1143452_fix

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.

b

The API must limit the exposure of endpoints.

CM-7 - Medium - CCI-000381 - V-274557 - SV-274557r1143590_rule

RMF Control

CM-7

Severity

M

CCI

CCI-000381

Version

SRG-APP-000141-API-000245

Vuln IDs

V-274557

Rule IDs

SV-274557r1143590_rule

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.

Checks: C-78658r1143454_chk

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.

Fix: F-78563r1142482_fix

Build or configure the API to limit the endpoint against improper exposure.

b

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).

IA-2 - Medium - CCI-000764 - V-274559 - SV-274559r1143592_rule

RMF Control

IA-2

Severity

M

CCI

CCI-000764

Version

SRG-APP-000148-API-000255

Vuln IDs

V-274559

Rule IDs

SV-274559r1143592_rule

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.

Checks: C-78660r1143456_chk

Review the API documentation and interview the API administrator to determine access methods to the API. Attempt 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. If the API does not use an approved DOD enterprise ICAM solution for external clients to establish initial access, this is a finding.

Fix: F-78565r1142488_fix

Configure the API to use an approved DOD enterprise ICAM solution.

b

The API must protect Session IDs via encryption.

SC-23 - Medium - CCI-001184 - V-274600 - SV-274600r1143633_rule

RMF Control

SC-23

Severity

M

CCI

CCI-001184

Version

SRG-APP-000219-API-000460

Vuln IDs

V-274600

Rule IDs

SV-274600r1143633_rule

Encrypting Session IDs protects them from interception and unauthorized access, preventing session hijacking and ensuring the confidentiality and integrity of user sessions.

Checks: C-78701r1143458_chk

Verify the API protects Session IDs. Review the API documentation and configuration. Interview the API administrator and obtain implementation documentation identifying system architecture. Identify the API communication paths. This includes system-to-system communication and client-to-server communication that transmit session identifiers over the network. Have 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. The protections must be implemented on a point-to-point basis based upon the architecture of the API. For 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. If the API session IDs are unencrypted across network segments, this is a finding.

Fix: F-78606r1142611_fix

Build or configure the API to protect session IDs from interception or from manipulation.

b

The API keys must be securely generated using a FIPS-validated Random Number Generator (RNG).

SC-23 - Medium - CCI-001188 - V-274603 - SV-274603r1143636_rule

RMF Control

SC-23

Severity

M

CCI

CCI-001188

Version

SRG-APP-000224-API-000475

Vuln IDs

V-274603

Rule IDs

SV-274603r1143636_rule

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. Unique 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. DRBGs (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.

Checks: C-78704r1143460_chk

This requirement is applicable only to devices that use a web interface for device management. Verify the API keys are securely generated using a FIPS-validated RNG. Review the API documentation and interview the API administrator. Identify the cryptographic modules utilized by the API for key generation. Identify 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. If the API does not use a FIPS 140-3-approved RNG, this is a finding.

Fix: F-78609r1143461_fix

This requirement is applicable only to devices that use a web interface for device management. Build or configure the API to use FIPS 140-3-validated cryptographic modules when the API implements RNGs for key generation.

b

The API implementation must use FIPS-validated encryption and hashing algorithms to protect the confidentiality and integrity of API keys.

SC-28 - Medium - CCI-001199 - V-274606 - SV-274606r1143639_rule

RMF Control

SC-28

Severity

M

CCI

CCI-001199

Version

SRG-APP-000231-API-000490

Vuln IDs

V-274606

Rule IDs

SV-274606r1143639_rule

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. Store API keys securely, avoiding plaintext storage.

Checks: C-78707r1143463_chk

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.

Fix: F-78612r1142629_fix

Identify data elements that require protection. Document the data types and specify protection requirements and methods used.

c

The API must encrypt sensitive cached data.

SC-28 - High - CCI-001199 - V-274607 - SV-274607r1143640_rule

RMF Control

SC-28

Severity

H

CCI

CCI-001199

Version

SRG-APP-000231-API-000495

Vuln IDs

V-274607

Rule IDs

SV-274607r1143640_rule

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.

Checks: C-78708r1142631_chk

Verify the API encrypts sensitive data when it is cached. If the API does not encrypt sensitive cached data, this is a finding.

Fix: F-78613r1142632_fix

Build or configure the API to encrypt sensitive data when cached.

b

The API must employ throttling.

SC-5 - Medium - CCI-001095 - V-274612 - SV-274612r1143931_rule

RMF Control

SC-5

Severity

M

CCI

CCI-001095

Version

SRG-APP-000247-API-000520

Vuln IDs

V-274612

Rule IDs

SV-274612r1143931_rule

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. In 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. The 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.

Checks: C-78713r1143930_chk

Review the API architecture documentation and identify solutions that provide API DoS protections. Verify the API employs throttling to limit the effects of information flooding attacks. This includes: - Requests per second. - Sliding window algorithm. - Request queues. - Reduce parallelism and call frequency. If the API does not employ throttling to limit the effects of information flooding attacks, this is a finding.

Fix: F-78618r1142647_fix

Build or configure the API to employ throttling to limit the effects of information flooding attacks.

b

The API must specify allowed origins when using Cross-Origin Resource Sharing (CORS).

SI-10 - Medium - CCI-001310 - V-274613 - SV-274613r1143646_rule

RMF Control

SI-10

Severity

M

CCI

CCI-001310

Version

SRG-APP-000251-API-000525

Vuln IDs

V-274613

Rule IDs

SV-274613r1143646_rule

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. Checking 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.

Checks: C-78714r1142649_chk

If CORS is not in use, this requirement is not applicable. Verify the API specifies origins when using CORS. If the API is using CORS and does not specify allowed origins, this is a finding.

Fix: F-78619r1142650_fix

Build or configure the API to specify allowed origins when using CORS.

b

The API must not disclose sensitive data in error messages.

SI-11 - Medium - CCI-001312 - V-274615 - SV-274615r1143648_rule

RMF Control

SI-11

Severity

M

CCI

CCI-001312

Version

SRG-APP-000266-API-000535

Vuln IDs

V-274615

Rule IDs

SV-274615r1143648_rule

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. The 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. Mask or redact sensitive data in API responses.

Checks: C-78716r1142655_chk

Review the API documentation and interview the API administrator for details regarding how the API displays error messages. Utilize the API as a nonprivileged user and attempt to execute functionality that will generate error messages. Review the error messages displayed to ensure no sensitive information is provided to end users. If 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. If 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.

Fix: F-78621r1142656_fix

Build or configure the API to not send error messages containing system information or sensitive data to users. Use generic error messages.

b

Access to API privileged features and functions must be restricted.

AC-6 - Medium - CCI-002235 - V-274643 - SV-274643r1143676_rule

RMF Control

AC-6

Severity

M

CCI

CCI-002235

Version

SRG-APP-000340-API-000675

Vuln IDs

V-274643

Rule IDs

SV-274643r1143676_rule

Preventing nonprivileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges. Privileged 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. One method to meet this requirement is to separate APIs into roles and functions to limit access based on need.

Checks: C-78744r1143467_chk

Review access controls for API privileged features and functions (administrative operations, configuration management, data modification, and access to sensitive information). If unauthorized users can access any of these privileged capabilities, this is a finding.

Fix: F-78649r1143468_fix

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.

b

The API must require periodic reauthentication.

IA-11 - Medium - CCI-002038 - V-274672 - SV-274672r1143705_rule

RMF Control

IA-11

Severity

M

CCI

CCI-002038

Version

SRG-APP-000389-API-000820

Vuln IDs

V-274672

Rule IDs

SV-274672r1143705_rule

Without reauthentication, resources may be accessed without authorization. When APIs provide the capability to change security roles or escalate the functional capability of the application, it is critical the user reauthenticate. In 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. (i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) When the execution of privileged functions occurs; (v) After a fixed period of time (ex. 24 hours); or (vi) Periodically. Within the DOD, the minimum circumstances requiring reauthentication are privilege escalation and role changes.

Checks: C-78773r1142826_chk

Verify the API requires periodic reauthentication. If the API does not require reauthentication periodically, this is a finding.

Fix: F-78678r1142827_fix

Build or configure the API to require reauthentication periodically.

b

The API must have a mechanism for cache invalidation when using cache policy data.

IA-5 - Medium - CCI-002007 - V-274677 - SV-274677r1143710_rule

RMF Control

IA-5

Severity

M

CCI

CCI-002007

Version

SRG-APP-000400-API-000845

Vuln IDs

V-274677

Rule IDs

SV-274677r1143710_rule

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.

Checks: C-78778r1143470_chk

Verify the API has a mechanism for cache invalidation when using cache policy data. It 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. If the API is not configured to expire cache policy data, this is a finding.

Fix: F-78683r1142842_fix

Build or configure the API to expire the cache policy data.

b

When stateless authentication tokens are used, the API must configure them with appropriate security settings.

IA-5 - Medium - CCI-002007 - V-274678 - SV-274678r1143711_rule

RMF Control

IA-5

Severity

M

CCI

CCI-002007

Version

SRG-APP-000400-API-000850

Vuln IDs

V-274678

Rule IDs

SV-274678r1143711_rule

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. The API must configure tokens for stateless authentication to ensure secure validation, prevent unauthorized access, and maintain integrity without relying on server-side sessions.

Checks: C-78779r1143472_chk

Verify the API configures tokens with the appropriate security settings, when stateless authentication tokens are used. 1. 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. If an expiration time is not configured in accordance with organizational defined limits, this is a finding. 2. 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. Check 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. 3. The key value must be stored in a data vault solution. Check application configuration files. Check environment variables referencing vault storage. If a key value is not stored in a data vault solution, this is a finding.

Fix: F-78684r1143473_fix

Build or configure tokens for stateless authentication to ensure secure validation, prevent unauthorized access, and maintain integrity without relying on server-side sessions. 1. Configure expiration time in accordance with organizational defined limits. 2. Configure the token secret key to be a dynamic variable represented by an environmental variable or specified in an environment data file. 3. Store the key value in a data vault solution.

b

The API's internal authorization tokens must not be provided back to the user.

IA-5 - Medium - CCI-002007 - V-274679 - SV-274679r1143712_rule

RMF Control

IA-5

Severity

M

CCI

CCI-002007

Version

SRG-APP-000400-API-000855

Vuln IDs

V-274679

Rule IDs

SV-274679r1143712_rule

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.

Checks: C-78780r1143379_chk

Verify the API's internal authorization tokens are not provided back to the user. Inspect 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. Audit API documentation: Review the API documentation to see if the token is explicitly mentioned as being returned to the user. If internal tokens are part of any public documentation for user-facing APIs, this is a finding.

Fix: F-78685r1142848_fix

Review the API and authentication codebase. Remove internal tokens being passed around or exposed at any point in the code.

b

API access tokens must be configured to expire.

IA-5 - Medium - CCI-002007 - V-274680 - SV-274680r1143713_rule

RMF Control

IA-5

Severity

M

CCI

CCI-002007

Version

SRG-APP-000400-API-000860

Vuln IDs

V-274680

Rule IDs

SV-274680r1143713_rule

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. If cached authentication information is out of date, the validity of the authentication information may be questionable.

Checks: C-78781r1143475_chk

Verify API access tokens are configured to expire according to organizational defined parameters. If API access tokens are not configured to expire according to organizational defined parameters, this is a finding.

Fix: F-78686r1143476_fix

Build or configure API access tokens to expire according to organizational defined parameters.

b

API refresh tokens must be configured to expire.

IA-5 - Medium - CCI-002007 - V-274681 - SV-274681r1143714_rule

RMF Control

IA-5

Severity

M

CCI

CCI-002007

Version

SRG-APP-000400-API-000865

Vuln IDs

V-274681

Rule IDs

SV-274681r1143714_rule

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.

Checks: C-78782r1143478_chk

Verify API refresh tokens are configured to expire according to organizational defined parameters. If API refresh tokens are not configured to expire according to organizational defined parameters, this is a finding.

Fix: F-78687r1143479_fix

Build or configure API refresh tokens to expire according to organizational defined parameters.

b

The API must enforce per-client rate limits.

SC-5 - Medium - CCI-001095 - V-274682 - SV-274682r1143925_rule

RMF Control

SC-5

Severity

M

CCI

CCI-001095

Version

SRG-APP-000247-API-000870

Vuln IDs

V-274682

Rule IDs

SV-274682r1143925_rule

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.

Checks: C-78783r1143923_chk

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. Verify that: - Each client has an independent rate limit (e.g., requests per second/minute/hour). - Limits are enforced consistently across API endpoints. - Clients exceeding the limit receive appropriate error responses (e.g., HTTP 429 Too Many Requests). - The rate limiting configuration aligns with organizational performance and security policies. Acceptable evidence may include Gateway/service configuration files or dashboards (e.g., AWS API Gateway, NGINX). API documentation defining rate limits per client. Logs showing enforcement of limits for individual clients. If the API does not enforce per-client rate limits, or if limits are global, improperly configured, or unenforced, this is a finding.

Fix: F-78688r1143924_fix

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. Ensure that: - Each client has a defined threshold for request rates. - Limits are enforced dynamically. - Clients exceeding limits receive appropriate error responses. Update system documentation to reflect the implemented rate-limiting policy and enforcement mechanisms.

b

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.

SC-16 - Medium - CCI-002455 - V-274697 - SV-274697r1143731_rule

RMF Control

SC-16

Severity

M

CCI

CCI-002455

Version

SRG-APP-000419-API-000945

Vuln IDs

V-274697

Rule IDs

SV-274697r1143731_rule

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. By 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. It 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.

Checks: C-78798r1143481_chk

Note: The authorizing official (AO) may conduct a risk assessment if not using an API Gateway. Check Client API Endpoints: Examine 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. Review 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. If the API is not configured to route requests through a single, authorized API Gateway endpoint, this is a finding.

Fix: F-78703r1142902_fix

Clients must be configured to call a single API gateway URL rather than accessing backend services directly.

b

The API must use a gateway.

SC-5 - Medium - CCI-002385 - V-274707 - SV-274707r1143741_rule

RMF Control

SC-5

Severity

M

CCI

CCI-002385

Version

SRG-APP-000435-API-000995

Vuln IDs

V-274707

Rule IDs

SV-274707r1143741_rule

API Gateway acts as a centralized point for managing and securing API traffic, enhancing the overall security posture of an API ecosystem. The 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. It 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.

Checks: C-78808r1143483_chk

Note: The authorizing official (AO) may conduct a risk assessment if not using an API Gateway. The 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. If the API does not use a gateway, this is a finding.

Fix: F-78713r1142932_fix

Build or configure the API to use a gateway.

c

The amount of data returned by the API must be restricted.

SC-8 - High - CCI-002418 - V-274709 - SV-274709r1143744_rule

RMF Control

SC-8

Severity

H

CCI

CCI-002418

Version

SRG-APP-000439-API-001005

Vuln IDs

V-274709

Rule IDs

SV-274709r1143744_rule

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.

Checks: C-78810r1143485_chk

Verify the amount of data returned by the API is restricted. Check API endpoints: Review 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). If 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.

Fix: F-78715r1143743_fix

Ensure API responses are small and contain only the data necessary for the client's request. To 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.

c

The API must use TLS version 1.2 at a minimum.

SC-8 - High - CCI-002418 - V-274710 - SV-274710r1143745_rule

RMF Control

SC-8

Severity

H

CCI

CCI-002418

Version

SRG-APP-000439-API-001010

Vuln IDs

V-274710

Rule IDs

SV-274710r1143745_rule

Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered. This 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. Communication 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.

Checks: C-78811r1143487_chk

Verify the API uses TLS version 1.2 at a minimum. Review the API documentation and interview the API administrator. Identify API clients, servers and associated network connections including API networking ports. Review API documents for instructions or guidance on configuring API encryption settings. Verify 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. If the API does not utilize TLS or another approved encryption mechanism to protect the confidentiality and integrity of transmitted information, this is a finding.

Fix: F-78716r1143488_fix

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.

b

The API must audience-restrict access tokens in accordance with organization-defined identification and authentication policy.

SC-8 - Medium - CCI-002420 - V-274712 - SV-274712r1143748_rule

RMF Control

SC-8

Severity

M

CCI

CCI-002420

Version

SRG-APP-000441-API-001020

Vuln IDs

V-274712

Rule IDs

SV-274712r1143748_rule

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. Without 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.

Checks: C-78813r1143747_chk

Review the API's token issuance process, specifically for access tokens (e.g., JWTs or OAuth2 tokens). Inspect the aud (audience) claim in the access tokens to verify that it is present and correctly populated with the intended audience identifier(s). Confirm that audience restrictions align with the organization's identification and authentication policy, ensuring that tokens are scoped only to authorized APIs, services, or clients. Review access control and validation logic in the API or resource server to ensure that incoming tokens are validated against the expected audience value. Interview the system owner or developer to verify how audience values are defined, issued, and enforced. If access tokens are not audience-restricted or if the audience values do not comply with the organization-defined policy, this is a finding.

Fix: F-78718r1142947_fix

Build or configure the API to audience restrict access tokens in accordance with organization-defined identification and authentication policy.

b

The API must use parameterized queries.

SI-10 - Medium - CCI-002754 - V-274714 - SV-274714r1143751_rule

RMF Control

SI-10

Severity

M

CCI

CCI-002754

Version

SRG-APP-000447-API-001030

Vuln IDs

V-274714

Rule IDs

SV-274714r1143751_rule

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. The 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.

Checks: C-78815r1143750_chk

Review the API's source code or backend database interaction layer. Identify all database queries constructed using user-supplied input. Verify that parameterized queries (also known as prepared statements) are used instead of dynamically constructed SQL strings with input concatenation. Confirm that query parameters are bound using the appropriate method for the language or database framework (e.g., ?, named parameters, or bind variables). If any queries use string concatenation or interpolation of user input without parameterization, this is a finding.

Fix: F-78720r1142953_fix

Follow best practice when accepting user input and verify all input is validated before the API processes the input. Remediate identified vulnerabilities and obtain documented risk acceptance for those issues that cannot be remediated immediately.

b

The API must provide input validation.

SI-10 - Medium - CCI-002754 - V-274715 - SV-274715r1143753_rule

RMF Control

SI-10

Severity

M

CCI

CCI-002754

Version

SRG-APP-000447-API-001035

Vuln IDs

V-274715

Rule IDs

SV-274715r1143753_rule

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. The 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.

Checks: C-78816r1143752_chk

Verify the API provides input validation. Review the API documentation and interview the API administrator. Review the API's input handling mechanisms at all exposed endpoints. Identify all points where user input is accepted, including query parameters, headers, body content, and path variables. Verify that input validation is implemented to enforce expected formats, data types, ranges, and lengths. Ensure validation occurs on the server side, regardless of any client-side checks. Check for validation against known-safe patterns or whitelists (e.g., regex, enumerated values) and proper rejection of malformed or unexpected input. If input validation is missing, insufficient, or only enforced on the client side, this is a finding.is is a finding.

Fix: F-78721r1142956_fix

Follow best practice when accepting user input and verify all input is validated before the API processes the input. Remediate identified vulnerabilities and obtain documented risk acceptance for those issues that cannot be remediated immediately.

b

The API must authenticate remote commands.

Medium - CCI-003747 - V-274723 - SV-274723r1143761_rule

RMF Control

Severity

M

CCI

CCI-003747

Version

SRG-APP-000461-API-001075

Vuln IDs

V-274723

Rule IDs

SV-274723r1143761_rule

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. Cryptographic mechanisms can be employed, for example, to authenticate remote commands. Safeguards include, at a minimum, FIPS-compliant cryptographic hash. Standard API authentication protocols provide this protection (e.g., Oauth 2.0, JWT).

Checks: C-78824r1142979_chk

Verify the API authenticates remote commands. If the API does not authenticate remote commands, this is a finding.

Fix: F-78729r1142980_fix

Build or configure the API to authenticate remote commands.

b

The API must encode outputs.

CM-6 - Medium - CCI-000366 - V-274767 - SV-274767r1143805_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

SRG-APP-000516-API-001295

Vuln IDs

V-274767

Rule IDs

SV-274767r1143805_rule

Output encoding ensures data sent from an API is properly formatted and does not cause unintended effects on the receiving end. Requiring an API to encode its outputs is a security measure to prevent Cross-Site Scripting (XSS), HTTP Response Splitting, and Log Injection vulnerabilities. Without 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. Improperly encoded responses could allow attackers to manipulate HTTP headers, causing response splitting that may facilitate cache poisoning or session fixation. Unencoded user input in logs could introduce log injection issues, obscuring attack traces or triggering unintended system behavior. Encoding output ensures special characters are safely represented, preventing unintended execution or injection attacks.

Checks: C-78868r1143111_chk

Verify the API encodes outputs. If the API does not encode outputs, this is a finding.

Fix: F-78773r1143112_fix

Build or configure the API to encode outputs.

b

The API must use a static type of system.

CM-6 - Medium - CCI-000366 - V-274768 - SV-274768r1143806_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

SRG-APP-000516-API-001300

Vuln IDs

V-274768

Rule IDs

SV-274768r1143806_rule

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.

Checks: C-78869r1143403_chk

Verify the API is using a static type system. 1. 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. 2. Look for explicit type annotations in function signatures, variables, and data structures. 3. Review the project's dependencies to see if type-checking tools or frameworks (e.g., TypeScript for JavaScript, MyPy for Python) are used. 4. Check for the presence of static type checking in the build or compilation process, which ensures type correctness before runtime. If the API is not a static type system, this is a finding.

Fix: F-78774r1143404_fix

Redesign the API to use a static type of system.

b

The API must use Web Application Firewall (WAF).

CM-6 - Medium - CCI-000366 - V-274769 - SV-274769r1143807_rule

RMF Control

CM-6

Severity

M

CCI

CCI-000366

Version

SRG-APP-000516-API-001305

Vuln IDs

V-274769

Rule IDs

SV-274769r1143807_rule

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.

Checks: C-78870r1143496_chk

Verify the API is configured to use a WAF or API Gateway to manage traffic. If the API is not configured to use a WAF or API Gateway in accordance with organization-defined security policies, this is a finding.

Fix: F-78775r1143118_fix

Build or configure the API to use a WAF or API Gateway to manage traffic.

b

The API must use a FIPS-validated cryptographic module to provision digital signatures for tokens.

SC-13 - Medium - CCI-002450 - V-274783 - SV-274783r1143932_rule

RMF Control

SC-13

Severity

M

CCI

CCI-002450

Version

SRG-APP-000630-API-001375

Vuln IDs

V-274783

Rule IDs

SV-274783r1143932_rule

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. The 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.

Checks: C-78884r1143159_chk

Verify the API must use a FIPS-validated cryptographic module to provision digital signatures for tokens. Authentication 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. Services 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. If the API does not use a FIPS validated cryptographic module to provision signatures for tokens, this is a finding.

Fix: F-78789r1143160_fix

Build or configure the API to utilize a FIPS-validated cryptographic module to provision digital signatures.

b

API services identified within the system as unnecessary and/or nonsecure must be disabled.

CM-7 - Medium - CCI-000382 - V-274785 - SV-274785r1143921_rule

RMF Control

CM-7

Severity

M

CCI

CCI-000382

Version

SRG-APP-000645-API-001385

Vuln IDs

V-274785

Rule IDs

SV-274785r1143921_rule

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. APIs 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). Examples 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.

Checks: C-78886r1143920_chk

Verify API services identified within the system as unnecessary and/or nonsecure are disabled. Review the API documentation and configuration. Interview the API administrator. Identify the services, network ports, and protocols used by the API. Using 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. Review the Ports, Protocols, and Services Management (PPSM) Category Assurance List (CAL) at https://cyber.mil/ppsm/cal/. Verify the ports used by the API are approved by the PPSM CAL. If the ports and services are not approved by the PPSM CAL, this is a finding.

Fix: F-78791r1143409_fix

Build or configure the API to use necessary and secure services and ports approved by the PPSM CAL.

b

The API must provide protected storage for API keys.

Medium - CCI-004910 - V-274830 - SV-274830r1143869_rule

RMF Control

Severity

M

CCI

CCI-004910

Version

SRG-APP-000915-API-001610

Vuln IDs

V-274830

Rule IDs

SV-274830r1143869_rule

API key exposure introduces security vulnerabilities to hosted applications. Store API keys securely, avoiding plaintext storage. Avoid plain text storage within application code or application source trees.

Checks: C-78931r1143499_chk

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. If the API is not configured to provide protected storage for API keys, this is a finding.

Fix: F-78836r1143500_fix

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.

b

API must use a circuit breaker pattern to handle failures and timeouts.

Medium - CCI-004992 - V-274835 - SV-274835r1143875_rule

RMF Control

Severity

M

CCI

CCI-004992

Version

SRG-APP-000945-API-001635

Vuln IDs

V-274835

Rule IDs

SV-274835r1143875_rule

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.

Checks: C-78936r1143874_chk

Verify the API uses a circuit breaker pattern to handle failures and timeouts. Review 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. If a circuit breaker pattern is not being used, this a finding.

Fix: F-78841r1143316_fix

Configure the API to use a circuit breaker pattern to handle failures and timeouts.

b

Cryptographic keys that protect access tokens must be protected.

Medium - CCI-005156 - V-274839 - SV-274839r1143880_rule

RMF Control

Severity

M

CCI

CCI-005156

Version

SRG-APP-000965-API-001655

Vuln IDs

V-274839

Rule IDs

SV-274839r1143880_rule

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. By securing the cryptographic keys, the API mitigates the potential for security breaches and upholds a strong defense against various attack vectors.

Checks: C-78940r1143879_chk

To check if cryptographic keys that protect access tokens are properly protected in an API: 1. Verify a proper key management system (KMS) is in place to generate, store, and rotate cryptographic keys. 2. Verify that keys are generated and stored using best practices, ensuring they are never exposed in plaintext. 3. Verify keys are stored securely. 4. Verify keys are not hardcoded in application code or exposed in configuration files. 5. 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. 6. Verify key rotation procedures are in place, and cryptographic keys are rotated regularly to mitigate the risk of key compromise. 7. 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. 8. Review the API's documentation to ensure that cryptographic keys are managed and protected according to security guidelines (e.g., NIST, FIPS). If cryptographic keys are not properly protected, this is a finding.

Fix: F-78845r1143328_fix

Build or configure the API to properly protect cryptographic keys that protect access tokens.

b

The API must protect the private keys used to sign assertions and tokens.

Medium - CCI-005157 - V-274840 - SV-274840r1143882_rule

RMF Control

Severity

M

CCI

CCI-005157

Version

SRG-APP-000970-API-001660

Vuln IDs

V-274840

Rule IDs

SV-274840r1143882_rule

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. The 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.

Checks: C-78941r1143881_chk

To check if the API protects the private keys used to sign assertions and tokens: Verify 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. Verify 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. Verify only authorized personnel or systems can access the keys. Review filesystem permissions. Verify 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. Verify private keys are only used for their intended purpose—signing tokens and assertions. Audit the system to ensure that keys are only accessible during token generation or signing processes and not left accessible longer than needed. Confirm 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. Implement 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. Review 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. If the API is not protecting private keys, this is a finding.

Fix: F-78846r1143331_fix

Build or configure the API to properly protect private keys used to sign assertions and tokens.

b

Generating assertions must be restricted.

Medium - CCI-005158 - V-274841 - SV-274841r1143884_rule

RMF Control

Severity

M

CCI

CCI-005158

Version

SRG-APP-000975-API-001665

Vuln IDs

V-274841

Rule IDs

SV-274841r1143884_rule

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.

Checks: C-78942r1143883_chk

Review the API's authentication and authorization mechanisms. Ensure that the assertions are generated using the correct identity source's identity provider (IdP). Verify the API adheres to the defined authentication standards to ensure only authenticated and authorized entities can generate assertions. Check the assertions include necessary identity information (e.g., user ID, roles, and claims) and are signed or encrypted. Verify the generation process is compliant with any guidelines regarding assertion lifetime, scope, and audience. Review system logs to confirm the API is correctly implementing the authentication policies and generating assertions only after successful identity verification. Consult the organization's identity management documentation and compare it to the API's implementation to ensure full alignment with the defined policies. If the API is not generating assertions in accordance with organization-defined identification and authentication policy, this is a finding.

Fix: F-78847r1143504_fix

Build or configure the API to generate assertions in accordance with organization-defined identification and authentication policy.

b

The API must issue assertions in accordance with organization-defined identification and authentication policy.

Medium - CCI-005159 - V-274842 - SV-274842r1143886_rule

RMF Control

Severity

M

CCI

CCI-005159

Version

SRG-APP-000980-API-001670

Vuln IDs

V-274842

Rule IDs

SV-274842r1143886_rule

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.

Checks: C-78943r1143885_chk

Reviewing the API's authentication and authorization mechanisms. Verify the assertions are issued using the correct identity source's identity provider (IdP). Verify the API adheres to the defined authentication standards to ensure that only authenticated and authorized entities can issue assertions. Check the assertions include necessary identity information (e.g., user ID, roles, and claims) and are signed or encrypted. Validate the issued process is compliant with any guidelines regarding assertion lifetime, scope, and audience. Check 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. Consult the organization's identity management documentation and compare it to the API's implementation to ensure full alignment with the defined policies. If the API is not issuing assertions in accordance with organization-defined identification and authentication policy, this is a finding.

Fix: F-78848r1143337_fix

Build or configure the API to issue assertions in accordance with organization-defined identification and authentication policy.

b

The API must refresh assertions in accordance with organization-defined identification and authentication policy.

Medium - CCI-005160 - V-274843 - SV-274843r1143888_rule

RMF Control

Severity

M

CCI

CCI-005160

Version

SRG-APP-000985-API-001675

Vuln IDs

V-274843

Rule IDs

SV-274843r1143888_rule

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.

Checks: C-78944r1143887_chk

Check if the API refreshes assertions in accordance with the organization-defined identification and authentication policy. Review the API's handling of assertion expiration and renewal. Ensure the API follows the organization's defined policies for assertion lifetime, including the duration before assertions need to be refreshed or reissued. Check 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. Verify the process for refreshing assertions maintains security standards, including proper encryption, secure token storage, and validation of the refreshed assertions before they are issued. Review 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. Test 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. If the API does not refresh assertions in accordance with organization-defined identification and authentication policy, this is a finding.

Fix: F-78849r1143340_fix

Build or configure the API to refresh assertions in accordance with organization-defined identification and authentication policy.

b

The API must revoke assertions in accordance with organization-defined identification and authentication policy.

Medium - CCI-005161 - V-274844 - SV-274844r1143890_rule

RMF Control

Severity

M

CCI

CCI-005161

Version

SRG-APP-000990-API-001680

Vuln IDs

V-274844

Rule IDs

SV-274844r1143890_rule

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.

Checks: C-78945r1143889_chk

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. Simulate 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. Review Logging and Auditing of Revocation Events: Confirm that the API logs revocation events, capturing key details such as who initiated the revocation, when it occurred, and why it was revoked. After 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. Refer 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. If the API does not revoke assertions in accordance with organization-defined identification and authentication policy, this is a finding.

Fix: F-78850r1143343_fix

Build or configure the API to revoke assertions in accordance with organization-defined identification and authentication policy.

b

The API must time-restrict assertions in accordance with organization-defined identification and authentication policy.

Medium - CCI-005162 - V-274845 - SV-274845r1143892_rule

RMF Control

Severity

M

CCI

CCI-005162

Version

SRG-APP-000995-API-001685

Vuln IDs

V-274845

Rule IDs

SV-274845r1143892_rule

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.

Checks: C-78946r1143891_chk

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. Check 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. Simulate 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. Verify 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. Review 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. Refer 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. If the API does not time restrict assertions in accordance with organization-defined identification and authentication policy, this is a finding.

Fix: F-78851r1143346_fix

Build or configure the API to time-restrict assertions in accordance with organization-defined identification and authentication policy.

b

The API must audience-restrict assertions in accordance with organization-defined identification and authentication policy.

Medium - CCI-005163 - V-274846 - SV-274846r1143894_rule

RMF Control

Severity

M

CCI

CCI-005163

Version

SRG-APP-001000-API-001690

Vuln IDs

V-274846

Rule IDs

SV-274846r1143894_rule

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.

Checks: C-78947r1143893_chk

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. Check 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. Simulate 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. Verify the audience values specified in the assertions align with the organization's policy. Check 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. If 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. Review 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. If the API does not audience restrict assertions in accordance with organization-defined identification and authentication policy, this is a finding.

Fix: F-78852r1143349_fix

Build or configure the API to audience-restrict assertions in accordance with organization-defined identification and authentication policy.

b

The API must generate access tokens in accordance with organization-defined identification and authentication policy.

Medium - CCI-005164 - V-274847 - SV-274847r1143896_rule

RMF Control

Severity

M

CCI

CCI-005164

Version

SRG-APP-001005-API-001695

Vuln IDs

V-274847

Rule IDs

SV-274847r1143896_rule

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. Without 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.

Checks: C-78948r1143895_chk

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. Examine 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. Generate 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. Attempt 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. If 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. If the API does not generate access tokens in accordance with organization-defined identification and authentication policy, this is a finding.

Fix: F-78853r1143352_fix

Build or configure the API to generate access tokens in accordance with organization-defined identification and authentication policy.

b

The API must issue access tokens in accordance with organization-defined identification and authentication policy.

Medium - CCI-005165 - V-274848 - SV-274848r1143898_rule

RMF Control

Severity

M

CCI

CCI-005165

Version

SRG-APP-001010-API-001700

Vuln IDs

V-274848

Rule IDs

SV-274848r1143898_rule

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. Without 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.

Checks: C-78949r1143897_chk

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. Perform 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. Attempt 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. Check that the token is signed or encrypted using the approved cryptographic algorithms. Ensure keys are securely managed and that tokens cannot be tampered with. Verify 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. Review API or identity provider documentation to confirm whether token issuance behavior aligns with organizational requirements. If any misconfigurations are identified, this is a finding.

Fix: F-78854r1143355_fix

Build or configure the API to issue access tokens in accordance with organization-defined identification and authentication policy.

b

The API must refresh access tokens in accordance with organization-defined identification and authentication policy.

Medium - CCI-005166 - V-274849 - SV-274849r1143900_rule

RMF Control

Severity

M

CCI

CCI-005166

Version

SRG-APP-001015-API-001705

Vuln IDs

V-274849

Rule IDs

SV-274849r1143900_rule

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. If 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.

Checks: C-78950r1143899_chk

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. Simulate 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. Verify 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. Examine 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. Consult the API or identity provider documentation and configuration to verify refresh behavior is implemented in accordance with the defined organizational standards. If any misconfigurations are identified, this is a finding.

Fix: F-78855r1143358_fix

Build or configure the API to refresh access tokens in accordance with organization-defined identification and authentication policy.

b

The API must revoke access tokens in accordance with organization-defined identification and authentication policy.

Medium - CCI-005167 - V-274850 - SV-274850r1143901_rule

RMF Control

Severity

M

CCI

CCI-005167

Version

SRG-APP-001020-API-001710

Vuln IDs

V-274850

Rule IDs

SV-274850r1143901_rule

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. Without 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.

Checks: C-78951r1143360_chk

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. Use 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. If tokens are cached or used across distributed systems, verify revocation is promptly propagated and enforced across all relevant services in accordance with policy requirements. If 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. Consult API or identity provider documentation to confirm support for revocation features and verify they are configured to align with organizational policies. If any misconfigurations are identified, this is a finding.

Fix: F-78856r1143361_fix

Build or configure the API to revoke access tokens in accordance with organization-defined identification and authentication policy.

b

The API must time-restrict access tokens in accordance with organization-defined identification and authentication policy.

Medium - CCI-005168 - V-274851 - SV-274851r1143903_rule

RMF Control

Severity

M

CCI

CCI-005168

Version

SRG-APP-001025-API-001715

Vuln IDs

V-274851

Rule IDs

SV-274851r1143903_rule

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. Without 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.

Checks: C-78952r1143902_chk

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. Review 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. Authenticate 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. Wait 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). Determine 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. Ensure the API validates the exp claim on each request and denies access to expired tokens. Look into API or identity provider configuration files to confirm that token timeout values match policy-defined thresholds. If any misconfigurations are identified, this is a finding.

Fix: F-78857r1143364_fix

Build or configure the API to revoke access tokens in accordance with organization-defined identification and authentication policy.

Content changes 54

Checks: C-78598r1142301_chk

Fix: F-78503r1142302_fix

Generate Mitigation Statement:

Checks: C-78608r1143926_chk

Fix: F-78513r1143421_fix

Generate Mitigation Statement:

Checks: C-78618r1143423_chk

Fix: F-78523r1142362_fix

Generate Mitigation Statement:

Checks: C-78620r1143425_chk

Fix: F-78525r1142368_fix

Generate Mitigation Statement:

Checks: C-78621r1143427_chk

Fix: F-78526r1142371_fix

Generate Mitigation Statement:

Checks: C-78623r1143429_chk

Fix: F-78528r1142377_fix

Generate Mitigation Statement:

Checks: C-78624r1143431_chk

Fix: F-78529r1143432_fix

Generate Mitigation Statement:

Checks: C-78625r1143434_chk

Fix: F-78530r1142383_fix

Generate Mitigation Statement:

Checks: C-78626r1143928_chk

Fix: F-78531r1142386_fix

Generate Mitigation Statement:

Checks: C-78627r1143551_chk

Fix: F-78532r1142389_fix

Generate Mitigation Statement:

Checks: C-78628r1143440_chk

Fix: F-78533r1142392_fix

Generate Mitigation Statement:

Checks: C-78629r1142394_chk

Fix: F-78534r1142395_fix

Generate Mitigation Statement:

Checks: C-78630r1143442_chk

Fix: F-78535r1142398_fix

Generate Mitigation Statement:

Checks: C-78631r1143556_chk

Fix: F-78536r1142401_fix

Generate Mitigation Statement:

Checks: C-78632r1143558_chk

Fix: F-78537r1142404_fix

Generate Mitigation Statement:

Checks: C-78633r1143560_chk

Fix: F-78538r1142407_fix

Generate Mitigation Statement:

Checks: C-78634r1143562_chk

Fix: F-78539r1142410_fix

Generate Mitigation Statement:

Checks: C-78635r1143564_chk

Fix: F-78540r1142413_fix

Generate Mitigation Statement:

Checks: C-78638r1143568_chk

Fix: F-78543r1143569_fix

Generate Mitigation Statement:

Checks: C-78657r1143451_chk

Fix: F-78562r1143452_fix

Generate Mitigation Statement:

Checks: C-78658r1143454_chk

Fix: F-78563r1142482_fix

Generate Mitigation Statement:

Checks: C-78660r1143456_chk

Fix: F-78565r1142488_fix

Generate Mitigation Statement:

Checks: C-78701r1143458_chk

Fix: F-78606r1142611_fix

Generate Mitigation Statement:

Checks: C-78704r1143460_chk

Fix: F-78609r1143461_fix

Generate Mitigation Statement:

Checks: C-78707r1143463_chk

Fix: F-78612r1142629_fix

Generate Mitigation Statement:

Checks: C-78708r1142631_chk

Fix: F-78613r1142632_fix

Generate Mitigation Statement:

Checks: C-78713r1143930_chk