| V-274607 | high | The API must encrypt sensitive cached data. | 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. |
| V-274709 | high | The amount of data returned by the API must be restricted. | 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. |
| V-274710 | high | The API must use TLS version 1.2 at a minimum. | 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. |
| V-274497 | medium | The API must encrypt data in transit. | 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. |
| V-274507 | medium | The API must be configured to use approved authorizations for access control. | 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). |
| V-274517 | medium | The API must enable monitoring and alerts. | 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. |
| V-274519 | medium | The API Gateway must generate audit records when successful/unsuccessful attempts to access privileges occur. | 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. |
| V-274520 | medium | The API must generate audit records when successful/unsuccessful attempts to access privileges occur. | 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. |
| V-274522 | medium | The API Gateway must generate audit records of what type of events occurred. | 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. |
| V-274523 | medium | The API must monitor the usage of API keys to detect any anomalies. | 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. |
| V-274524 | medium | The API must generate audit records of what type of events occurred. | 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. |
| V-274525 | medium | The API must audit rate-limiting events. | 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. |
| V-274526 | medium | The API Gateway must audit rate limiting events. | 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. |
| V-274527 | medium | The API Gateway must audit authentication and authorization information. | 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. |
| V-274528 | medium | The API must audit authentication and authorization information. | 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. |
| V-274529 | medium | The API Gateway must audit exceptions and errors that occur during the processing. | 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. |
| V-274530 | medium | The API must audit exceptions and errors that occur during the processing. | 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. |
| V-274531 | medium | The API Gateway must audit execution time and performance metrics. | 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. |
| V-274532 | medium | The API must audit execution time and performance metrics. | 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. |
| V-274533 | medium | The API Gateway must audit request and response details (such as method, URL, headers, body, status, etc.). | 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. |
| V-274534 | medium | The API must audit request and response details (such as method, URL, headers, body, status, etc.). | 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. |
| V-274537 | medium | All defined API elements must be documented. | 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. |
| V-274556 | medium | API keys must be configured with usage restrictions. | 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. |
| V-274557 | medium | The API must limit the exposure of endpoints. | 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. |
| V-274559 | medium | 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). | 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. |
| V-274600 | medium | The API must protect Session IDs via encryption. | Encrypting Session IDs protects them from interception and unauthorized access, preventing session hijacking and ensuring the confidentiality and integrity of user sessions. |
| V-274603 | medium | The API keys must be securely generated using a FIPS-validated Random Number Generator (RNG). | 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. |
| V-274606 | medium | The API implementation must use FIPS-validated encryption and hashing algorithms to protect the confidentiality and integrity of API keys. | 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. |
| V-274612 | medium | The API must employ throttling. | 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. |
| V-274613 | medium | The API must specify allowed origins when using Cross-Origin Resource Sharing (CORS). | 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. |
| V-274615 | medium | The API must not disclose sensitive data in error messages. | 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. |
| V-274643 | medium | Access to API privileged features and functions must be restricted. | 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. |
| V-274672 | medium | The API must require periodic reauthentication. | 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. |
| V-274677 | medium | The API must have a mechanism for cache invalidation when using cache policy data. | 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. |
| V-274678 | medium | When stateless authentication tokens are used, the API must configure them with appropriate security settings. | 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. |
| V-274679 | medium | The API's internal authorization tokens must not be provided back to the user. | 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. |
| V-274680 | medium | API access tokens must be configured to expire. | 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. |
| V-274681 | medium | API refresh tokens must be configured to expire. | 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. |
| V-274682 | medium | The API must enforce per-client rate limits. | 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. |
| V-274697 | medium | 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. | 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. |
| V-274707 | medium | The API must use a gateway. | 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. |
| V-274712 | medium | The API must audience-restrict access tokens in accordance with organization-defined identification and authentication policy. | 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. |
| V-274714 | medium | The API must use parameterized queries. | 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. |
| V-274715 | medium | The API must provide input validation. | 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. |
| V-274723 | medium | The API must authenticate remote commands. | 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). |
| V-274767 | medium | The API must encode outputs. | 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. |
| V-274768 | medium | The API must use a static type of system. | 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. |
| V-274769 | medium | The API must use Web Application Firewall (WAF). | 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. |
| V-274783 | medium | The API must use a FIPS-validated cryptographic module to provision digital signatures for tokens. | 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. |
| V-274785 | medium | API services identified within the system as unnecessary and/or nonsecure must be disabled. | 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. |
| V-274830 | medium | The API must provide protected storage for API keys. | 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. |
| V-274835 | medium | API must use a circuit breaker pattern to handle failures and timeouts. | 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. |
| V-274839 | medium | Cryptographic keys that protect access tokens must be protected. | 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. |
| V-274840 | medium | The API must protect the private keys used to sign assertions and tokens. | 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. |
| V-274841 | medium | Generating assertions must be restricted. | 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. |
| V-274842 | medium | The API must issue assertions in accordance with organization-defined identification and authentication policy. | 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. |
| V-274843 | medium | The API must refresh assertions in accordance with organization-defined identification and authentication policy. | 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. |
| V-274844 | medium | The API must revoke assertions in accordance with organization-defined identification and authentication policy. | 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. |
| V-274845 | medium | The API must time-restrict assertions in accordance with organization-defined identification and authentication policy. | 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. |
| V-274846 | medium | The API must audience-restrict assertions in accordance with organization-defined identification and authentication policy. | 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. |
| V-274847 | medium | The API must generate access tokens in accordance with organization-defined identification and authentication policy. | 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. |
| V-274848 | medium | The API must issue access tokens in accordance with organization-defined identification and authentication policy. | 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. |
| V-274849 | medium | The API must refresh access tokens in accordance with organization-defined identification and authentication policy. | 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. |
| V-274850 | medium | The API must revoke access tokens in accordance with organization-defined identification and authentication policy. | 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. |
| V-274851 | medium | The API must time-restrict access tokens in accordance with organization-defined identification and authentication policy. | 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. |