Introduction
In this article, we discuss enabling a second-level Web Application Firewall (WAF) using Skycloak for your Keycloak cluster.
Skycloak is a fully managed Keycloak platform hosted in the cloud. It enables organizations to leverage the powerful capabilities of the open-source Keycloak Identity and Access Management (IAM) solution without the operational overhead of installing, maintaining, and scaling Keycloak for production-grade environments. All of this is delivered in a secure and cost-effective manner.
To further strengthen security, Skycloak provides several enterprise-grade protection mechanisms, including:
- Web Application Firewall (WAF)
- Geo-blocking
- IP-based access control
- Rate limiting
In this article, we focus specifically on the configurable WAF offered by Skycloak to secure your Keycloak cluster.
Overview
Skycloak provides built-in configurable security controls to protect your Keycloak cluster from external security threats. When a cluster is created, these features are available but not enabled by default. You are advised to achieve a risk-free security score, as shown in Skycloak Console -> Security, by enabling the recommended security features.
The second-level WAF feature discussed in this article is in addition to the default WAF available at the edge level. This configurable second-level WAF provides rich security capabilities.
Detection Modes
Supports two detection modes.
- Detect Only
- Log threats without blocking
- Block
- Actively block detected threats
Paranoia Level
The WAF supports multiple paranoia levels:
- Level 1
- Basic protection with minimal false positives
- Level 2
- Moderate protection, balanced for most applications
- Level 3
- Enhanced protection, may have some false positives
- Level 4
- Maximum protection, higher chance of false positives
Higher paranoia levels increase the likelihood of false positives, which may cause legitimate requests to fail. Therefore, it is recommended to start with a lower paranoia level in production environments.
In this article, Level 2 is used for the test case, as it provides moderate protection. Each request is inspected by the configured security checks before entering the Keycloak cluster.
OWASP Core Rule Set (OWASP CRS) Selection Options
Skycloak supports the following CRS selection options:
- Full CRS Protection- 600-800+ rules
- Complete OWASP Core Rule Set with all security categories enabled. Provides maximum protection against web attacks.
- Best for: Production applications requiring comprehensive security
- OWASP Top 10 Protection – 100-150 rules
- Covers OWASP Top 10 vulnerabilities including SQL injection, XSS, and RCE
- Balanced protection with minimal false positives
- Custom Categories
- Select specific attack categories to protect against. Fine-grained control over which rules are active.
- Best for: Fine-tuned protection or specific compliance requirements
OWASP Top 10 Protection is the default option when WAF is enabled and is recommended for most applications, as it provides strong security with low maintenance.
Skycloak also provides advanced exclusion and tuning options, which are useful for avoiding false positives based on application-specific behaviour.
For more details on OWASP ModSecurity Core Rule Set (CRS), please refer the link available here.
Configuration Steps
In this test case, Level 2 paranoia level and OWASP Top 10 Protection are used.
Navigate to:
Skycloak Console -> Security (Configuration tab)
Navigate to the Web Application Firewall section and perform the following steps:
Under the Web Application Firewall section, perform the following steps:
- Toggle the Web Application Firewall to Enabled
- Keep Detection Mode as Detect Only (for the initial test)
- Set Paranoia Level to Level 2
- Keep Rule Preset as OWASP Top 10 Protectio
Testing the Implementation
To verify the WAF configuration, we simulate a reflected XSS attack.
Try accessing your Keycloak cluster using the following request:
url -i \
-A "Mozilla/5.0" \
"https://your_kecyloak_hostname/realms/master/.well-known/openid-configuration?<script>alert(1)</script>"
At this stage, the WAF is configured in Detection Mode -> Detect Only.
Since the request is not blocked, it reaches Keycloak. However, the WAF generates security logs indicating an XSS detection.
You can view these logs in:
Skycloak Console -> Security -> Logs tab
Because the request reaches Keycloak, the following response is returned:
HTTP/1.1 400 Bad Request
content-length: 0
x-envoy-upstream-service-time: 8
date: Mon, 19 Jan 2026 08:34:44 GMT
server: istio-envoyThis response indicates that Keycloak correctly rejected the malformed request and is not vulnerable to the tested XSS vector.
Blocking the Request
Repeat the same test after changing the Detection Mode to Block.
The response will now be similar to the following:
HTTP/1.1 403 Forbidden
date: Mon, 19 Jan 2026 08:51:07 GMT
server: istio-envoy
content-length: 0
x-envoy-upstream-service-time: 2In this case, the request is blocked before entering the Keycloak cluster. Note the reduced x-envoy-upstream-service-time, indicating that the request was stopped at the WAF layer. The corresponding security logs can be reviewed in the Security -> Logs tab section.
Additional information:
Key OWASP CRS rule groups include:
942xxx-> SQL Injection941xxx-> XSS930xxx-> Path Traversal932xxx-> Command Injection921xxx-> Protocol violations
In this test case, rule IDs in the 941xxx range (such as 941110 or 941160) are triggered, indicating an XSS attack.
Summary
In this article, we explored how to secure a Keycloak cluster using the configurable WAF provided by Skycloak. By starting with detection mode and a moderate paranoia level, organizations can safely observe and tune security rules before enforcing blocking mode.
This layered security approach helps protect critical IAM endpoints from common web attacks while ensuring that legitimate authentication flows remain unaffected.
If you’re new to Skycloak, visit the Skycloak Getting Started Guide to learn more and securing your Keycloak deployments.