Findings

Access logging should be configured for API Gateway V2 Stages

Updated: June 19, 2025

Description

Severity: Low

The API Gateway V2 stage is not configured for access logging.

Access logs capture important details about incoming requests and outgoing responses, such as request patterns, source IP addresses, request headers, and status codes. Without access logging, the following risks are posed:

  • Lack of Visibility: API usage patterns, errors, and performance metrics cannot be tracked, making it difficult to understand the health of the API or identify potential issues.
  • Troubleshooting Challenges: If there is an issue with the API, such as a failure to process requests, the lack of logs means that you won't have enough data to diagnose the root cause.
  • Security Risks: Without logs, malicious activity such as unauthorized access attempts or abuse of API endpoints can go unnoticed, increasing the risk of breaches or misuse.

Example Attack

An attacker attempts a brute-force attack against an API endpoint by making multiple unauthorized requests to guess valid API keys or credentials. Without access logging, there's no record of these suspicious request patterns, making it harder to detect and mitigate the attack. If access logging were enabled, the attack would be visible in the logs, enabling the security team to detect the unusual number of failed requests from a particular IP address and block the source before the attack escalates.

Remediation

Set up access logging with CloudWatch API logging using the API Gateway console.

Security Frameworks

When transferring information between different security domains, record and audit content filtering actions and results for the information being filtered.

  1. Identify the types of events that the system is capable of logging in support of the audit function: [Assignment: organization-defined event types that the system is capable of logging];
  2. Coordinate the event logging function with other organizational entities requiring audit-related information to guide and inform the selection criteria for events to be logged;
  3. Specify the following event types for logging within the system: [Assignment: organization-defined event types (subset of the event types defined in AU-2a.) along with the frequency of (or situation requiring) logging for each identified event type];
  4. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and
  5. Review and update the event types selected for logging [Assignment: organization-defined frequency].

Ensure that audit records contain information that establishes the following:

  1. What type of event occurred;
  2. When the event occurred;
  3. Where the event occurred;
  4. Source of the event;
  5. Outcome of the event; and
  6. Identity of any individuals, subjects, or objects/entities associated with the event.

Analyze and correlate audit records across different repositories to gain organization-wide situational awareness.

Provide and implement the capability to centrally review and analyze audit records from multiple components within the system.

Provide irrefutable evidence that an individual (or process acting on behalf of an individual) has performed [Assignment: organization-defined actions to be covered by non-repudiation].

  1. Provide audit record generation capability for the event types the system is capable of auditing as defined in AU-2a on [Assignment: organization-defined system components];
  2. Allow [Assignment: organization-defined personnel or roles] to select the event types that are to be logged by specific components of the system; and
  3. Generate audit records for the event types defined in AU-2c that include the audit record content defined in AU-3.

Develop a system-level continuous monitoring strategy and implement continuous monitoring in accordance with the organization-level continuous monitoring strategy that includes:

  1. Establishing the following system-level metrics to be monitored: [Assignment: organization-defined system-level metrics];
  2. Establishing [Assignment: organization-defined frequencies] for monitoring and [Assignment: organization-defined frequencies] for assessment of control effectiveness;
  3. Ongoing control assessments in accordance with the continuous monitoring strategy;
  4. Ongoing monitoring of system and organization-defined metrics in accordance with the continuous monitoring strategy;
  5. Correlation and analysis of information generated by control assessments and monitoring;
  6. Response actions to address results of the analysis of control assessment and monitoring information; and
  7. Reporting the security and privacy status of the system to [Assignment: organization-defined personnel or roles] [Assignment: organization-defined frequency].

(a) Detect and deny outgoing communications traffic posing a threat to external systems; and
(b) Audit the identity of internal users associated with denied communications.

Upon detection of a potential integrity violation, provide the capability to audit the event and initiate the following actions: [Selection (one or more): generate an audit record; alert current user; alert [Assignment: organization-defined personnel or roles]; [Assignment: organization-defined other actions]].

Previous (Findings - Action based findings)
XSS attack vulnerability