Total newb: What's a good first rule to write for a public API?

As a practitioner primarily focused on analytics and user behavior, I've found that securing a public API shares a foundational principle with setting up a proper experiment: you must first establish a baseline control to filter out irrelevant noise. For a public API, this initial "control" is often a rate limiting rule. It is the most pragmatic first rule because it directly mitigates brute-force attacks, credential stuffing, and unintended resource exhaustion, which are among the most common and immediately damaging threats to an exposed endpoint.

When configuring AWS WAF as your first line of defense, I recommend starting with a rate-based rule (RBR) on what you deem your most critical POST or login endpoint. The objective is to allow legitimate user traffic while curtailing automated abuse. A methodical approach involves:

* **Initial Baseline Measurement:** Before deploying the rule, analyze 7-14 days of traffic logs (CloudWatch Logs Insights is suitable here) to establish a legitimate request-per-minute baseline for a single IP address. Look at the 95th or 99th percentile to avoid outliers.
* **Conservative Initial Threshold:** Set your first threshold slightly above this measured baseline. A common starting point for a login API might be 100 requests per 5-minute period from a single IP, but this is highly dependent on your product's usage patterns.
* **Action:** Start with a `Count` action for a monitoring period, then move to `Block`.

A basic CloudFormation snippet for such a rule might look like this:

```yaml
MyFirstRateLimitRule:
Type: AWS::WAFv2::RuleGroup
Properties:
Capacity: 100
Scope: REGIONAL
VisibilityConfig:
SampledRequestsEnabled: true
CloudWatchMetricsEnabled: true
MetricName: MyFirstRateLimitRule
Rules:
- Name: RateLimitLoginAPI
Priority: 1
Action:
Block: {}
VisibilityConfig:
SampledRequestsEnabled: true
CloudWatchMetricsEnabled: true
MetricName: RateLimitLoginAPI
Statement:
RateBasedStatement:
Limit: 100
AggregateKeyType: IP
ScopeDownStatement:
AndStatement:
Statements:
- ByteMatchStatement:
FieldToMatch:
UriPath:
MatchPattern:
Contains: "/api/v1/auth/login"
PositionalConstraint: CONTAINS
SearchString: "/api/v1/auth/login"
TextTransformations:
- Priority: 0
Type: NONE
- ByteMatchStatement:
FieldToMatch:
Method:
MatchPattern:
Contains: "POST"
PositionalConstraint: EXACTLY
SearchString: "POST"
TextTransformations:
- Priority: 0
Type: NONE
```

Key considerations for your first rule:
* **Evaluation & Iteration:** This rule must be treated as a hypothesis. You will need to monitor CloudWatch metrics for false positives (blocked legitimate users) and adjust the threshold accordingly. Consider creating a dashboard for this rule's metrics.
* **Complementary Logging:** Ensure your Web ACL is configured to log all requests to an S3 bucket or CloudWatch Logs. This log data is critical for post-incident analysis and refining your rules.
* **Next Steps:** After stabilizing this rule, your subsequent rules should likely focus on the OWASP Core Rule Set (CRS) to address common injection attacks, followed by custom rules tailored to your specific API schema and expected payload structures.

— Amanda