12.1 OCI Web Application Firewall: Policies, Modules, Actions & Enforcement Points
Key Takeaways
A regional WAF policy works as a plug-in for an OCI load balancer, connected through a firewall resource that links the policy to the enforcement point.
An edge policy is a global solution that requires pointing DNS at an Oracle-provided CNAME and allowlisting Oracle edge nodes.
WAF actions are Allow, which skips the remaining rules in the current module, Check, which only logs, and Return HTTP response.
Each WAF rule condition is written as a JMESPath expression evaluated against the HTTP request or response.
Collaborative protection capabilities require several individual capabilities to match, weighted against a threshold, to reduce false positives.
Why WAF Is Separate From the Network Firewall
The Network Firewall inspects all kinds of IP traffic in a VCN. Web Application Firewall (WAF) focuses on HTTP and HTTPS requests to web applications. It understands URLs, headers, query strings, and bodies, so it can stop application-layer attacks such as cross-site scripting (XSS), SQL injection, and other OWASP-defined vulnerabilities, apply access rules by geography or request signature, and rate-limit abusive clients. Oracle describes WAF as a PCI-compliant service.
Two Ways to Deploy WAF
| Option | Scope | How traffic reaches it | Typical use |
|---|---|---|---|
| WAF policy | Regional | Works as a plug-in for an OCI load balancer | Applications already behind an OCI load balancer |
| Edge policy | Global | DNS points the application at an Oracle-provided CNAME, and the origin allowlists Oracle's edge nodes | Global edge protection in front of an origin |
There is no automated tool to convert an edge policy into a WAF policy or the reverse; you recreate the settings manually.
For the regional option, a firewall resource (a WAF resource, not the Network Firewall) is the logical link between a WAF policy and an enforcement point such as a load balancer.
WAF Policy Modules
A WAF policy is organized into modules that inspect different parts of the transaction:
| Module | What it does |
|---|---|
| Request access control | Inspects request properties, such as source IP, country, path, or headers, and can return a defined HTTP response |
| Request rate limiting | Inspects connection properties and limits the frequency of requests for a key, such as each client IP |
| Request protection | Enables OCI-managed protection capabilities that check request content for malicious patterns |
| Response access control | Inspects response properties and can return a defined HTTP response |
| Response protection | Enables OCI-managed protection capabilities for HTTP responses |
Rules, Conditions, and Actions
Each rule has a condition written as a JMESPath expression that is evaluated against the HTTP request or response, and an action:
| Action | Behavior |
|---|---|
| Allow | When the rule matches, skip all remaining rules in the current module |
| Check | Do not stop rule processing; write a log entry documenting the result (useful for testing a rule before enforcing it) |
| Return HTTP response | Return a defined HTTP response, such as 401 or 403 with a custom body |
A safe rollout pattern is to create new rules with the Check action, review the logs for false positives, and then switch to Return HTTP response.
Network Address Lists
Network address lists hold public IP addresses and CIDR ranges, or private VCN addresses, that rules can reference. They make it easy to allow trusted partners, block known bad ranges, or exempt health checkers from rate limits.
Protection Capabilities
Request protection uses protection capabilities maintained by Oracle, each identified by a key and grouped by tags such as the attack type. You choose which capabilities to enable and what action to take when they match.
Collaborative protection capabilities reduce false positives. Instead of acting on one pattern, a collaborative capability runs a group of individual capabilities and adds up their weights. It acts only when the total reaches its action threshold. For example, a collaborative capability with key 9420000 runs individual capabilities such as 9421000, 9421400, and 9421600 for every request and takes action only if enough of them match.
Rate Limiting Design
Rate limiting protects login pages and APIs from brute-force and scraping attacks. Common choices:
- Apply rate limits per client IP on sensitive paths such as
/login. - Exempt monitoring systems through a network address list.
- Return a clear HTTP response, such as 429, when the limit is exceeded.
Certificates and TLS
For the regional option, TLS is terminated on the load balancer, which can use certificates managed by the OCI Certificates service. WAF then inspects the decrypted HTTP request before it is forwarded to the backends.
Tuning WAF Without Breaking the Application
New WAF policies often block legitimate traffic at first, such as large JSON bodies that look like injection attempts or API clients that send unusual headers. A practical tuning cycle is:
- Start new protection rules with Check so matches are only logged.
- Review the logged matches for each protection capability and identify false positives.
- Narrow conditions with JMESPath (for example, exclude a specific API path) or switch to a collaborative capability for noisy attack categories.
- Switch the reviewed rules to Return HTTP response and keep watching the logs after each application release.
Putting It Together: A Layered Web Architecture
- DNS resolves the application to a public load balancer, or to an edge policy's CNAME.
- The load balancer terminates TLS with a certificate from OCI Certificates.
- The WAF policy blocks injection attacks, enforces geography rules, and rate-limits abusive clients.
- Backends sit in private subnets protected by NSGs, and optionally ZPR.
- Traffic from the backends to databases can pass through a Network Firewall for deep inspection.
- Logging captures WAF decisions, and Cloud Guard watches for risky configuration.
Each layer covers a gap in the others: WAF understands HTTP, the Network Firewall understands traffic between networks, and NSGs and ZPR limit which components can talk at all.
A team wants to test new WAF request protection rules in production without blocking users, review what the rules would catch, and enforce them later. Which action should the rules use first?
Allow, because it records matches without changing any traffic
Return HTTP response with status 200, so that users are not blocked
Check, because it logs results without stopping rule processing
Disable the request protection module until testing is complete
An application runs behind an OCI load balancer in one region. The security team wants OWASP protections and per-client rate limiting without changing DNS to an external CNAME. Which WAF deployment fits?
A regional WAF policy linked to the load balancer through a WAF firewall resource
An edge policy, which attaches directly to the load balancer's listener
A Network Firewall policy with URL filtering placed in front of the load balancer
A security list rule that blocks requests containing SQL keywords
A WAF request protection setup produces many false positives because single patterns match harmless form submissions. Which feature is designed to reduce this?
Changing every request protection rule to the Allow action
A network address list that contains all known customer IP addresses
Moving the WAF policy to a different listener on the same public load balancer
Collaborative capabilities that act only above a weighted threshold
Sections you finish are checked off in the contents.