https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/ This chapter contains configuration guides for filtering. Hugo en-US https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/reduce-false-positives/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/reduce-false-positives/ Sometimes, requests are blocked by deny rules due to content resembling attacks but may be valid for a web application. These blocks are called false positives. You have several configuration options in the CR DenyRules if you have verified that the target web application is working correctly and a blocked request is a false positive. This article describes how and where to start reducing false positives. Narrowing down and reducing false positives This following instruction describes a best practice that helps narrow the scope and reduce false positives in most cases. https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/content-security-policy-header/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/content-security-policy-header/ A Content Security Policy (CSP) header is a passive security feature that can protect websites from attacks by defining a corresponding policy in the HTTP response header. The policy determines which resources (such as scripts, images, stylesheets, fonts, etc.) of a web page are considered safe and allowed to be loaded and executed by the browser. By controlling these resources, CSP helps to mitigate risks such as: Cross-site scripting (XSS), where malicious scripts are injected into a web page. Data Injection, where harmful data is introduced into a site that can be executed. Clickjacking, by preventing the site from being embedded into an iframe or a malicious page. Troubleshooting and integration Content Security Policies are not on/off directives but should be tailored to the application. Finding a strict production quality guideline for your application can be challenging, and the CSP standard constantly evolves. However, CSP-related resources and tools are freely available. https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/icap-integration/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/icap-integration/ Airlock Microgateway supports the Internet Content Adaptation Protocol (ICAP) as defined in RFC 3507. ICAP allows Microgateway to forward incoming HTTP requests to an external ICAP service before the requests reach the backend application. The main purpose of this integration is to scan incoming requests for malware, e.g., when clients upload files or submit content that should be inspected before it is processed by back-end services. This helps prevent malicious payloads from reaching protected applications. Beyond malware scanning, ICAP can also be used to inspect, analyze, and adapt requests by applying custom logic such as content checks, metadata enrichment, header or body rewrites, or request blocking. https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/openapi-specification-enforcement/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/openapi-specification-enforcement/ OpenAPI specification enforcement helps reduce an API’s attack surface by ensuring that only requests and responses that match the intended contract are accepted. Instead of relying solely on backend services to handle unexpected input, Airlock Microgateway validates traffic at the edge against a strict OpenAPI 3.0 definition. Requests that violate the specification are blocked. This makes APIs more resilient against malformed, undocumented, or malicious requests, improves consistency between producers and consumers, and helps detect integration errors early. https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/graphql-schema-validation/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/graphql-schema-validation/ GraphQL schema validation reduces the attack surface of GraphQL endpoints by ensuring that only requests matching the intended schema are accepted. Airlock Microgateway validates GraphQL traffic at the edge against a defined schema and blocks queries that violate it. This makes GraphQL APIs more resilient to malformed, undocumented, or malicious requests, improves consistency between clients and services, and helps detect integration errors early. It also lets you control whether introspection and mutations are allowed, so GraphQL endpoints expose only the operations intended for use. GraphQL queries, variables, and operation names can be extracted from either HTTP query parameters or JSON request bodies. https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/rate-limiting/ Mon, 01 Jan 0001 00:00:00 +0000 https://docs.airlock.com/microgateway/5.2/configuration-guides/filtering/rate-limiting/ This configuration guide shows how to limit the number of requests handled by Airlock Microgateway using the rate limit filter. Rate limiting is configured with a RateLimitPolicy. The policy is attached directly to an HTTPRoute and defines one or more rate limit policies for the routed traffic. Rate limits can apply to the entire route, to selected requests based on request conditions, or separately per client IP. Prerequisites A Gateway Deployment. An HTTPRoute routing traffic to your application. Configuration Limit all requests on a route Create a RateLimitPolicy in the same namespace as the HTTPRoute that you want to attach it to.