OCISecurityintermediate

OCI WAF Guide

Protect web applications with OCI WAF: protection rules, access control, bot management, rate limiting, custom rules, and monitoring.

CloudToolStack Team24 min readPublished Mar 14, 2026

Prerequisites

Understanding of web security concepts and OWASP Top 10
OCI account with WAF and load balancer permissions

Introduction to OCI Web Application Firewall

The OCI Web Application Firewall (WAF) is a cloud-based security service that protects web applications from common web exploits, bots, and distributed denial-of-service (DDoS) attacks. WAF inspects incoming HTTP/HTTPS traffic, evaluates it against configurable security rules, and either allows, blocks, or challenges requests based on the results. It integrates with OCI Load Balancer and OCI Flexible Load Balancer to provide seamless protection for web applications running on OCI.

OCI WAF provides protection against OWASP Top 10 vulnerabilities including SQL injection, cross-site scripting (XSS), remote file inclusion, and other common attack vectors. It also includes bot management capabilities to distinguish between legitimate users, good bots (search engines), and malicious automated traffic.

This guide covers WAF policy creation, protection rule configuration, access control lists, bot management, rate limiting, custom rules, and production deployment strategies for securing your web applications on OCI.

WAF Pricing

OCI WAF pricing is based on the number of requests processed per month. The first 10 million requests per month are included at no charge. Beyond that, pricing is approximately $0.60 per million requests. WAF policies and rules are free to create and maintain. This makes OCI WAF cost-effective even for high-traffic applications.

WAF Architecture and Deployment Models

OCI WAF can be deployed in two modes depending on your architecture:

Edge WAF Policy: Protects web applications by routing traffic through OCI's global edge network. DNS is pointed to OCI WAF, which inspects and filters traffic before forwarding clean requests to your origin server. This mode provides DDoS protection, global caching, and geographic distribution.

WAF Policy (Regional): Attaches directly to an OCI Load Balancer or Flexible Load Balancer within your VCN. Traffic is inspected as it passes through the load balancer, without routing through the edge network. This mode is simpler to deploy and is the recommended approach for applications already using OCI Load Balancer.

Both modes share the same rule engine, protection rules, and management APIs. The primary difference is the deployment topology and the additional edge features (CDN, DDoS) available with edge WAF policies.

bash

# Create a WAF policy (regional, attached to load balancer)
oci waf web-app-firewall create \
  --compartment-id $C \
  --display-name "production-waf" \
  --backend-type "LOAD_BALANCER" \
  --load-balancer-id <lb-ocid> \
  --web-app-firewall-policy-id <waf-policy-ocid> \
  --wait-for-state ACTIVE

# Create a WAF policy resource (contains rules)
oci waf web-app-firewall-policy create \
  --compartment-id $C \
  --display-name "standard-protection" \
  --actions '[
    {"type": "RETURN_HTTP_RESPONSE", "name": "block", "code": 403, "body": {"type": "STATIC_TEXT", "text": "Blocked by WAF"}},
    {"type": "ALLOW", "name": "allow"},
    {"type": "RETURN_HTTP_RESPONSE", "name": "rate-limited", "code": 429, "body": {"type": "STATIC_TEXT", "text": "Rate limit exceeded"}}
  ]' \
  --wait-for-state ACTIVE

# List WAF policies
oci waf web-app-firewall-policy list \
  --compartment-id $C \
  --query 'data.items[].{"display-name":"display-name", "lifecycle-state":"lifecycle-state"}' \
  --output table

# List WAF instances
oci waf web-app-firewall list \
  --compartment-id $C \
  --query 'data.items[].{"display-name":"display-name", "backend-type":"backend-type", "lifecycle-state":"lifecycle-state"}' \
  --output table

Protection Rules

Protection rules are the core security mechanism of OCI WAF. They inspect request headers, URI, query parameters, and request body for malicious patterns. OCI provides a comprehensive library of pre-built rules based on OWASP ModSecurity Core Rule Set (CRS) that cover common attack vectors.

Protection rules are organized into categories:

SQL Injection: Detects and blocks attempts to inject SQL statements into application queries through form fields, URL parameters, and cookies.

Cross-Site Scripting (XSS): Identifies and blocks script injection attacks that attempt to execute malicious JavaScript in users' browsers.

Remote File Inclusion (RFI): Blocks attempts to include remote files that could execute malicious code on the server.

Local File Inclusion (LFI): Prevents path traversal attacks that attempt to access files outside the web root directory.

Protocol Violations: Detects malformed HTTP requests that do not conform to HTTP standards and may indicate automated attack tools.

bash

# Create a WAF policy with protection rules
oci waf web-app-firewall-policy create \
  --compartment-id $C \
  --display-name "owasp-protection" \
  --actions '[
    {"type": "RETURN_HTTP_RESPONSE", "name": "block", "code": 403, "body": {"type": "STATIC_TEXT", "text": "Request blocked by security policy"}},
    {"type": "ALLOW", "name": "allow"}
  ]' \
  --request-protection '{"rules": [
    {
      "name": "sql-injection-protection",
      "type": "PROTECTION",
      "actionName": "block",
      "protectionCapabilities": [
        {"key": "941100", "version": 2, "exclusions": {}},
        {"key": "942100", "version": 2, "exclusions": {}},
        {"key": "942110", "version": 2, "exclusions": {}},
        {"key": "942120", "version": 2, "exclusions": {}}
      ],
      "isBodyInspectionEnabled": true
    },
    {
      "name": "xss-protection",
      "type": "PROTECTION",
      "actionName": "block",
      "protectionCapabilities": [
        {"key": "941100", "version": 2, "exclusions": {}},
        {"key": "941110", "version": 2, "exclusions": {}},
        {"key": "941120", "version": 2, "exclusions": {}}
      ],
      "isBodyInspectionEnabled": true
    }
  ]}' \
  --wait-for-state ACTIVE

# List available protection capabilities
oci waf protection-capability list \
  --compartment-id $C \
  --query 'data.items[].{key:key, "display-name":"display-name", type:type}' \
  --output table

Start in Detection Mode

When enabling new WAF protection rules, start in detection (log-only) mode rather than blocking mode. This allows you to review which requests would be blocked without impacting legitimate traffic. Monitor the WAF logs for false positives, create exclusions for legitimate patterns, and then switch to blocking mode once you are confident the rules are properly tuned. Aggressive blocking without tuning can break legitimate application functionality.

Access Control

Access control rules allow you to permit or deny traffic based on request attributes such as source IP address, geographic location, HTTP headers, and URL patterns. These rules are evaluated before protection rules and are useful for implementing IP allowlists, country-based restrictions, and path-based access controls.

bash

# Create access control rules in WAF policy
oci waf web-app-firewall-policy create \
  --compartment-id $C \
  --display-name "access-control-policy" \
  --actions '[
    {"type": "RETURN_HTTP_RESPONSE", "name": "block", "code": 403, "body": {"type": "STATIC_TEXT", "text": "Access denied"}},
    {"type": "ALLOW", "name": "allow"}
  ]' \
  --request-access-control '{"defaultActionName": "allow", "rules": [
    {
      "name": "block-suspicious-countries",
      "type": "ACCESS_CONTROL",
      "actionName": "block",
      "condition": "i_contains(connection.source.geo.countryCode, '\''XX'\'')",
      "conditionLanguage": "JMESPATH"
    },
    {
      "name": "allowlist-admin-ips",
      "type": "ACCESS_CONTROL",
      "actionName": "allow",
      "condition": "i_starts_with(http.request.uri.path, '\''admin'\'')",
      "conditionLanguage": "JMESPATH"
    },
    {
      "name": "block-known-bad-ips",
      "type": "ACCESS_CONTROL",
      "actionName": "block",
      "condition": "i_contains('\''192.0.2.1,198.51.100.1'\''connection.source.address)",
      "conditionLanguage": "JMESPATH"
    }
  ]}' \
  --wait-for-state ACTIVE

Bot Management

Bot management helps distinguish between legitimate human users, beneficial bots (search engine crawlers, monitoring bots), and malicious automated traffic (scrapers, credential stuffers, DDoS bots). OCI WAF provides bot detection using JavaScript challenge, CAPTCHA challenge, and device fingerprinting.

JavaScript Challenge: Requires the client to execute JavaScript, which filters out simple bots and scripts that do not render JavaScript. Transparent to human users with modern browsers.

CAPTCHA Challenge: Presents an interactive challenge that requires human input. Used for suspicious traffic that passes the JavaScript challenge but exhibits bot-like behavior.

Good Bot Allowlist: Maintains a list of known good bots (Googlebot, Bingbot, etc.) that should be allowed through without challenges. Verified by reverse DNS lookup to prevent spoofing.

bash

# Configure bot management in WAF policy
# Bot protection is configured through protection capabilities
# Key capabilities for bot detection:
#
# JavaScript Challenge:
# - Capability key: 950000 (JS challenge for suspicious requests)
#
# Human Interaction Challenge:
# - Verifies mouse movement, scrolling, and typing patterns
#
# Device Fingerprinting:
# - Collects browser and device characteristics to identify bots
#
# Good Bot Detection:
# - Identifies search engine crawlers by User-Agent and reverse DNS
# - Allows verified good bots to bypass challenges

# Example: WAF policy with bot management
# Configure through the OCI Console:
# 1. Navigate to WAF Policies
# 2. Select your policy
# 3. Click "Bot Management" tab
# 4. Enable JavaScript Challenge for suspicious traffic
# 5. Configure CAPTCHA threshold
# 6. Allowlist known good bots

# Monitor bot traffic
oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_waf" \
  --query-text 'BotRequests[5m]{resourceId = "<waf-ocid>"}.sum()'

oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_waf" \
  --query-text 'ChallengedRequests[5m]{resourceId = "<waf-ocid>"}.sum()'

Rate Limiting with WAF

WAF rate limiting controls the number of requests from a single source within a defined time window. Unlike API Gateway rate limiting which focuses on per-client API quotas, WAF rate limiting is designed to prevent abuse, brute force attacks, and application-layer DDoS attacks.

Rate limiting rules can be applied globally or scoped to specific URL paths, HTTP methods, or request characteristics. You can configure different rate limits for different parts of your application, for example a stricter limit on login endpoints to prevent credential stuffing.

bash

# WAF policy with rate limiting
oci waf web-app-firewall-policy create \
  --compartment-id $C \
  --display-name "rate-limited-policy" \
  --actions '[
    {"type": "RETURN_HTTP_RESPONSE", "name": "rate-limited", "code": 429, "body": {"type": "STATIC_TEXT", "text": "Too many requests"}},
    {"type": "ALLOW", "name": "allow"}
  ]' \
  --request-rate-limiting '{"rules": [
    {
      "name": "global-rate-limit",
      "type": "RATE_LIMITING",
      "actionName": "rate-limited",
      "configurations": [{
        "periodInSeconds": 60,
        "requestsLimit": 1000,
        "actionDurationInSeconds": 300
      }]
    },
    {
      "name": "login-rate-limit",
      "type": "RATE_LIMITING",
      "actionName": "rate-limited",
      "condition": "i_starts_with(http.request.uri.path, '\''login'\'')",
      "conditionLanguage": "JMESPATH",
      "configurations": [{
        "periodInSeconds": 60,
        "requestsLimit": 10,
        "actionDurationInSeconds": 600
      }]
    },
    {
      "name": "api-rate-limit",
      "type": "RATE_LIMITING",
      "actionName": "rate-limited",
      "condition": "i_starts_with(http.request.uri.path, '\''api'\'')",
      "conditionLanguage": "JMESPATH",
      "configurations": [{
        "periodInSeconds": 60,
        "requestsLimit": 200,
        "actionDurationInSeconds": 120
      }]
    }
  ]}' \
  --wait-for-state ACTIVE

Logging and Monitoring

WAF logging provides detailed visibility into every request processed by the firewall, including the action taken (allow, block, challenge), the rule that matched, the source IP, geographic information, and request details. These logs are essential for security analysis, incident investigation, and rule tuning.

WAF metrics in OCI Monitoring provide aggregate views of traffic patterns, block rates, and challenge completion rates. Use these metrics to create dashboards that show security posture at a glance and alarms that notify you of unusual activity.

bash

# Monitor WAF request metrics
oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_waf" \
  --query-text 'TotalRequests[5m]{resourceId = "<waf-ocid>"}.sum()'

# Monitor blocked requests
oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_waf" \
  --query-text 'BlockedRequests[5m]{resourceId = "<waf-ocid>"}.sum()'

# Monitor by rule type
oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_waf" \
  --query-text 'ProtectionRuleMatches[5m]{resourceId = "<waf-ocid>"}.sum()'

# Create alarm for high block rate
oci monitoring alarm create \
  --compartment-id $C \
  --display-name "waf-high-block-rate" \
  --metric-compartment-id $C \
  --namespace "oci_waf" \
  --query-text 'BlockedRequests[5m]{resourceId = "<waf-ocid>"}.sum() / TotalRequests[5m]{resourceId = "<waf-ocid>"}.sum() * 100 > 30' \
  --severity "WARNING" \
  --destinations '["<security-topic-ocid>"]' \
  --is-enabled true \
  --body "WAF blocking more than 30% of requests - possible attack or false positive issue"

# Create alarm for potential DDoS
oci monitoring alarm create \
  --compartment-id $C \
  --display-name "waf-possible-ddos" \
  --metric-compartment-id $C \
  --namespace "oci_waf" \
  --query-text 'TotalRequests[1m]{resourceId = "<waf-ocid>"}.sum() > 50000' \
  --severity "CRITICAL" \
  --destinations '["<critical-topic-ocid>"]' \
  --is-enabled true \
  --body "Unusually high request volume detected - possible DDoS attack"

# Enable WAF logging
# Configure through OCI Logging:
# 1. Create a Log Group for WAF logs
# 2. Enable the WAF service log
# 3. Logs will include: source IP, action, matched rules, request details

Custom Protection Rules

While the built-in protection rules cover the OWASP Top 10 and common attack patterns, you may need custom rules for application-specific threats. Custom rules use the JMESPath expression language to define conditions based on any request attribute.

bash

# Custom rule examples:

# Block requests with suspicious User-Agent strings
# "condition": "i_contains(http.request.headers.user-agent, 'sqlmap') || i_contains(http.request.headers.user-agent, 'nikto')"

# Block requests to sensitive paths
# "condition": "i_contains(http.request.uri.path, '.env') || i_contains(http.request.uri.path, 'wp-admin') || i_contains(http.request.uri.path, 'phpMyAdmin')"

# Block requests with excessively long URIs (potential buffer overflow)
# "condition": "length(http.request.uri.path) > 2048"

# Block requests with specific content types
# "condition": "http.request.headers.content-type == 'application/x-www-form-urlencoded' && length(http.request.body) > 1048576"

# Example: Create policy with custom rules
oci waf web-app-firewall-policy update \
  --web-app-firewall-policy-id <policy-ocid> \
  --request-protection '{"rules": [
    {
      "name": "block-attack-tools",
      "type": "ACCESS_CONTROL",
      "actionName": "block",
      "condition": "i_contains(http.request.headers.'\''user-agent'\'''\'', '\''sqlmap'\'')",
      "conditionLanguage": "JMESPATH"
    }
  ]}' \
  --wait-for-state ACTIVE

Production Best Practices

Deploying WAF in production requires a careful, phased approach to avoid disrupting legitimate traffic while maximizing security coverage:

Phased Rollout: Start by enabling WAF in detection mode for all protection rules. Monitor logs for 1-2 weeks to establish a baseline of normal traffic patterns. Identify and exclude false positives. Then switch to blocking mode for high-confidence rules (SQL injection, XSS) while keeping others in detection mode.

False Positive Management: False positives are inevitable with WAF. Create exclusions for known legitimate patterns, such as inline HTML/JavaScript in CMS content, SQL-like syntax in search queries, or special characters in form fields. Document all exclusions with the business justification.

Defense in Depth: WAF is one layer of your security stack. Combine it with NSGs for network-level filtering, OCI Identity Domains for authentication, input validation in your application code, and database-level security. No single security layer is sufficient on its own.

Regular Rule Updates: New vulnerabilities and attack techniques emerge constantly. Review and update your WAF rules quarterly. Oracle updates the protection capability library regularly, and new rules should be evaluated and enabled as appropriate.

Incident Response: Create runbooks for WAF-related incidents including DDoS attacks, application-layer attacks, and false positive escalations. Define clear procedures for temporarily bypassing WAF rules during emergencies without exposing the application to unnecessary risk.

OCI Load Balancer Deep Dive OCI Security Best Practices OCI API Gateway Guide

Key Takeaways

1OCI WAF protects against OWASP Top 10 including SQL injection, XSS, and remote file inclusion.
2Edge and regional deployment modes support different architectures and DDoS protection levels.
3Bot management uses JavaScript challenges, CAPTCHA, and device fingerprinting to detect automation.
4Start in detection mode to tune rules and prevent false positives before enabling blocking.

Frequently Asked Questions

How much does OCI WAF cost?

OCI WAF includes the first 10 million requests per month at no charge. Beyond that, pricing is approximately $0.60 per million requests. WAF policies and rules are free to create and maintain. This is significantly cheaper than AWS WAF ($5/month per web ACL plus $1/million requests) for most workloads.

Can OCI WAF protect non-OCI applications?

The edge WAF policy mode can protect any web application by routing DNS through OCI's edge network. The application can be hosted on any cloud provider or on-premises. Traffic is inspected at OCI's edge and clean traffic is forwarded to your origin server. The regional WAF mode requires an OCI Load Balancer and is limited to OCI-hosted applications.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.