AWS Web Application Firewall (WAF)

A web application firewall is in place to protect public-facing web applications from outside threats.

WAF should be appropriately deployed and configured to appropriately block malicious traffic.

There should be a single Global WAF ACL set.

If WAF is not enabled or there are no rulesets configured:

Recommended Solution:

Enable a Web Application Firewall (WAF) for all public-facing web applications. Configure it with standard security rulesets (e.g., OWASP Core Rule Set) to detect and block common attacks such as SQL injection, XSS, and request smuggling. Regularly update and tune the rules to minimize false positives.

Risks and Side Effects:

Implementing or tightening WAF rules may initially block legitimate traffic or cause application performance degradation if not tuned properly. Continuous monitoring and rule adjustments are required to balance security and usability.

How to Check if Affected Resources Handle Customer Data:

Review application documentation and data flow diagrams to determine which web applications process or serve customer data. Check whether endpoints behind the affected web servers are used for customer authentication, data input forms, or APIs that exchange customer information. If logs or configuration files reference customer databases or CRM integrations, those applications are considered to handle customer data.

What are the resources in aws that should be behind WAF?

In AWS, any internet-facing resource that serves web traffic or APIs should ideally be protected by a Web Application Firewall (WAF). Here’s a breakdown of the main AWS resources that should be behind WAF, depending on how your architecture is set up:

1. Amazon CloudFront Distributions

Why: CloudFront is often the first entry point for global web traffic. Applying WAF at this layer helps block malicious requests before they reach your origin servers.

Use case: Static websites, dynamic web applications, APIs, or content delivery networks (CDNs).

2. Application Load Balancers (ALB)

Why: ALBs route traffic to backend EC2 instances, containers, or Lambda functions. WAF at this level protects internal applications or microservices exposed to the internet.

Use case: Web apps, REST APIs, or services behind an ALB.

3. Amazon API Gateway

Why: API Gateway endpoints are public by default and can expose critical business logic. WAF helps prevent attacks like injection, scraping, and DoS attempts.

Use case: Public or partner-facing APIs.

4. AWS AppSync (GraphQL APIs)

Why: GraphQL APIs are vulnerable to overly complex queries and enumeration attacks. WAF can enforce query depth limits and request validation.

Use case: Mobile or web applications using GraphQL.

5. Amazon Cognito Hosted UI (optional)

Why: If you expose Cognito’s hosted UI for user sign-up or login, WAF can help protect against brute-force or injection attacks.

Use case: Authentication portals for customers or employees.

6. AWS Elastic Beanstalk Environments

Why: Beanstalk apps typically use an ALB or CloudFront. Apply WAF at the load balancer or CloudFront layer to protect the Beanstalk environment.

Use case: Managed web applications deployed through Elastic Beanstalk.

7. Public-Facing EC2 Instances (if not behind ALB)

Why: Directly exposed EC2 web servers are vulnerable entry points. A WAF can protect HTTP/HTTPS traffic through an AWS WAF-enabled CloudFront distribution or ALB placed in front.

Use case: Legacy applications or custom web servers.

Rule of Thumb

If the AWS resource:

• Accepts HTTP/HTTPS requests directly from the internet, and
• Handles customer data or serves data to customers

...then it should be behind AWS WAF (via CloudFront, ALB, or API Gateway integration).

AWS WAF Coverage Checklist

Here’s a short, practical checklist you can use to verify that all applicable AWS resources are protected by a WAF — either for internal compliance tracking (e.g., Drata) or automated auditing (e.g., AWS Config, Security Hub).

1. Identify Public-Facing Entry Points

 List all CloudFront distributions, ALBs, API Gateways, and AppSync APIs.

Use the AWS CLI or console:

aws cloudfront list-distributions

aws elbv2 describe-load-balancers

aws apigateway get-rest-apis

aws appsync list-graphql-apis

 Confirm which ones have a public DNS name or public IP (internet-facing).

2. Check for WAF Associations

 For each CloudFront distribution, confirm it has an associated WAF WebACL:

aws wafv2 list-web-acls --scope CLOUDFRONT

 For each Application Load Balancer:

aws wafv2 list-web-acls --scope REGIONAL

 For each API Gateway or AppSync API:

aws wafv2 list-web-acls --scope REGIONAL

 Verify that the WebACLs are actively associated with the resources above.

3. Review WAF Configuration

 Ensure WAF WebACLs use AWS Managed Rules (e.g., AWSManagedRulesCommonRuleSet, SQLiRuleSet).

 Check for custom rules or rate-based rules to block brute force or scraping.

 Verify logging is enabled to CloudWatch Logs or S3 for auditability.

4. Confirm Coverage for Customer-Data Applications

 Identify which web apps/APIs process customer data or serve data to customers (e.g., sign-in pages, dashboards, APIs).

 Ensure those endpoints are behind a CloudFront or ALB with WAF enabled.

 For internal-only services, document why WAF protection is not required (for audit traceability).

5. Ongoing Monitoring

 Enable AWS Config rule: wafv2-webacl-resource-association-check

→ Automatically detects if CloudFront, ALB, or API Gateway resources lack WAF association.

 Integrate findings into AWS Security Hub or Drata evidence collection for continuous compliance.

If ALB is created by internal-facing ingress, does it need to have WAF?

Scenario: ALB Created by Internal-Facing Ingress (e.g., via Kubernetes, EKS, or Terraform)

If the ALB is internal-facing only, meaning:

It has no public IP address,

It is not exposed to the internet, and

It only receives traffic from inside your VPC (e.g., from internal microservices, private APIs, or VPN users),

then you do not need to attach a WAF.

✅ Reasoning

AWS WAF is designed to protect HTTP(S) endpoints exposed to the public internet from malicious requests (SQLi, XSS, bots, etc.).

Internal ALBs are shielded by VPC network boundaries, security groups, and IAM roles, which already limit exposure.

Adding WAF to internal-only ALBs typically adds cost and latency without a real security benefit.

⚠️ When You Should Still Consider WAF

Attach WAF even for internal ALBs if any of the following apply:

The ALB fronts an API or app accessed by external partners over private link or VPN.

You handle sensitive customer data internally and want uniform request inspection (e.g., PCI or strict SOC 2 environment).

You want centralized logging and rule enforcement across all HTTP/S ingress points.

🔍 How to Verify if the ALB Is Internal

You can confirm by checking the Scheme attribute of the ALB:

aws elbv2 describe-load-balancers --query "LoadBalancers[*].{Name:LoadBalancerName, Scheme:Scheme, DNS:DNSName}"

If the scheme is:

"internet-facing" → WAF required

"internal" → WAF not required, unless exceptions above apply

🧩 In Compliance Context (e.g., Drata, SOC 2)

Document the reason for exclusion in your evidence (e.g., “ALB is internal-only and does not handle direct customer or internet traffic”).

Provide proof (screenshot or CLI output) showing the ALB scheme is "internal".

Reference your network segmentation policy or data flow diagram to show it’s isolated from public access.

Does internal-facing api gateway need to have WAF?

Amazon API Gateway can be internal-facing, and that directly affects whether it needs a WAF.

Here’s a clear breakdown:

⚙️ Internal-Facing API Gateway

1. How API Gateway Can Be Internal

You can make an API Gateway internal in two main ways:

Private API Endpoint Type

The API Gateway is accessible only within your VPC via interface VPC endpoints (AWS PrivateLink).

Endpoint type: PRIVATE

No public internet access.

Requests must originate from the same VPC or peered VPCs.

Regional API with Restrictive Access

The endpoint type is REGIONAL, but you restrict access via:

VPC security groups,

Resource policies (IP whitelisting or VPC endpoint restrictions), or

Custom authorizers (e.g., Cognito, Lambda) to block external access.

WAF Requirement

Scenario WAF Needed? Reason

Private API (endpoint type = PRIVATE) ❌ No Not exposed to the public internet. Traffic is internal to your VPC.

Regional/Public API (endpoint type = REGIONAL or EDGE) ✅ Yes Publicly reachable — must be protected from malicious web traffic.

Regional API with strict IP allow-list ⚠️ Optional Technically internal-only, but still reachable via public DNS — WAF can provide defense-in-depth.

How to Check API Type

You can verify the endpoint type with this AWS CLI command:

aws apigateway get-rest-apis --query "items[*].{Name:name, ID:id, EndpointType:endpointConfiguration.types}"

Look for:

"PRIVATE" → Internal

"REGIONAL" or "EDGE" → Internet-facing

🧩 Compliance (e.g., Drata, SOC 2, ISO 27001)

If the API Gateway is PRIVATE:

You can document it as not subject to WAF requirements because it is not internet-facing.

Include supporting evidence:

CLI output showing "endpointConfiguration": ["PRIVATE"]

Network diagram showing VPC-only access

Reference your access control policy

If the API Gateway is REGIONAL/EDGE:

Attach an AWS WAF WebACL to the API stage or distribution.

Use AWS Managed Rules to cover OWASP Top 10 threats.

Here’s a short, auditor-friendly justification you can paste directly into Drata (or your evidence documentation) for internal-facing API Gateways:

Justification:

This API Gateway uses the PRIVATE endpoint type and is only accessible within our AWS VPC via PrivateLink. It is not exposed to the public internet and therefore not subject to web-based attack vectors that AWS WAF protects against. Network access is restricted by VPC security groups and IAM resource policies, providing sufficient protection without WAF.

Here’s a version you can use for REGIONAL API Gateways that are technically public but tightly restricted (e.g., IP allow-lists, VPN access, or custom authorizers):

Justification:

This API Gateway uses the REGIONAL endpoint type but is restricted by IP allow-lists and VPC access controls, preventing access from the public internet. Only trusted corporate networks and VPN connections can reach the endpoint. Since external traffic is fully controlled and authenticated, the risk of web-based attacks is minimal, and AWS WAF is not required for this configuration.

Are There Internal-Facing CloudFront Distributions?

Not exactly — CloudFront is inherently public, because:

It is a global content delivery network (CDN) that uses public edge locations.

Every CloudFront distribution exposes a public DNS name (e.g., d123456abcdef.cloudfront.net).

It cannot be deployed inside a VPC or made truly private like an internal ALB or Private API Gateway.

However, you can restrict who can access a CloudFront distribution, effectively making it private in access, though not internal in networking terms.

🔒 Ways to Restrict Access to CloudFront

1. Origin Access Control / Origin Access Identity (OAC/OAI)

Use this to restrict CloudFront’s origin (e.g., S3, ALB) so that it only accepts traffic from CloudFront, not the public internet.

Prevents bypassing the CDN layer.

2. Signed URLs or Signed Cookies

Restricts who can access the distribution’s content by requiring valid signed requests (used for private content or authenticated delivery).

3. AWS WAF + Geo or IP Restrictions

Can be used to restrict access to certain IP ranges or geographies.

4. CloudFront + PrivateLink (advanced pattern)

Some advanced setups route CloudFront through an internal ALB or API Gateway behind PrivateLink, but the CloudFront endpoint itself remains public.

✅ WAF Requirement for CloudFront

Scenario WAF Needed? Reason

Public CloudFront (standard use case) ✅ Yes Public-facing CDN endpoint; exposed to web-based attacks.

CloudFront with signed URLs/cookies ✅ Recommended Still internet-facing; authentication adds control, but not full protection.

CloudFront used only as a secured delivery point for internal users (e.g., VPN-only or restricted IP ranges) ⚠️ Optional Publicly accessible but effectively restricted. WAF can still provide defense-in-depth.

CloudFront serving purely static, non-sensitive content (e.g., marketing site) ⚙️ Optional (documented exception) Low risk; can justify exclusion if risk assessment supports it.

🧩 Compliance Guidance (Drata, SOC 2, ISO 27001)

If your CloudFront distribution is public-facing or handles customer data, attach an AWS WAF WebACL.

If it’s restricted (e.g., by IP allow-list or signed URLs), you can justify exclusion by documenting:

Access controls in place (e.g., signed URLs, VPN, OAC).

That it does not handle customer or sensitive data.

That WAF exclusion is based on a risk assessment confirming minimal exposure.

📝 Drata Justification Example (for Restricted CloudFront)

Justification:

This CloudFront distribution is technically public but restricted via signed URLs and origin access controls, ensuring only authorized requests reach the origin. It does not host or process customer data, and access is limited to authenticated users. Given these layered controls and limited exposure, enabling AWS WAF is optional and has been risk-assessed as unnecessary.

Would you like me to create a short table summarizing all three services (ALB, API Gateway, CloudFront) — showing when WAF is required, optional, or not needed, with justification text for each? That’s often useful for Drata evidence uploads or internal compliance policy docs.