{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://atlas.maintz.dev/)"},"id":"security/web-application-firewall","url":{"en":"https://atlas.maintz.dev/en/terms/security/web-application-firewall/","da":"https://atlas.maintz.dev/da/terms/security/web-application-firewall/"},"term":{"en":"Web application firewall (WAF)","da":"Web application firewall (WAF)"},"aka":{"en":["WAF"],"da":["WAF"]},"domain":["security","cs"],"cluster":"application-security","layer":"application","status":"current","era":1999,"summary":{"en":"A filter in front of a website that reads each web request and blocks those that look like known attacks.","da":"Et filter foran et website, der læser hver webforespørgsel og blokerer dem, der ligner kendte angreb."},"body":{"formal":{"en":"A firewall that works at the level of HTTP rather than single packets, checking the content of each request to a web application - form fields, headers, cookie values - against rules for known attack patterns, and blocking or logging matches.","da":"En firewall, der arbejder på HTTP-niveau i stedet for med enkelte pakker og tjekker indholdet af hver forespørgsel til en webapplikation - formularfelter, headers, cookie-værdier - mod regler for kendte angrebsmønstre og blokerer eller logger dem, der matcher."},"plain":{"en":"Like a receptionist who opens every letter to a company and throws out the ones with a known scam inside, whereas an ordinary guard only checks the address on the envelope.","da":"Som en receptionist, der åbner alle breve til en virksomhed og smider dem ud, der indeholder et kendt fupnummer, hvor en almindelig vagt kun tjekker adressen på kuverten."},"inPractice":{"en":"IT operations in a region cannot fix a flaw in an old booking page this week, so they turn on a WAF rule that blocks requests with SQL commands in the search field until the supplier has fixed the code.","da":"IT-driften i en region kan ikke nå at rette en fejl i en gammel bookingside i denne uge og slår derfor en WAF-regel til, der blokerer forespørgsler med SQL-kommandoer i søgefeltet, indtil leverandøren har rettet koden."},"whyItMatters":{"en":"Web attacks pass straight through a normal firewall because they arrive through the same open door as real visitors; a WAF buys time, but a skilled attacker can often word a request to slip past its rules.","da":"Webangreb går lige igennem en almindelig firewall, fordi de kommer ind ad samme åbne dør som rigtige besøgende; en WAF køber tid, men en dygtig angriber kan ofte formulere en forespørgsel, så den slipper forbi reglerne."}},"deepDive":{"en":"A WAF terminates or inspects HTTP(S) traffic at layer 7, which means it must see decrypted traffic: it either terminates TLS itself as a reverse proxy, runs as a module inside the web server or ingress controller, or is delivered as a cloud or CDN edge service. Deployment modes include inline blocking, transparent bridging and out-of-band monitoring from a traffic copy, which can detect but not block. It parses the request into components such as method, URI, query arguments, headers, cookies and a body decoded as form data, JSON, XML or multipart, normalises encodings, and evaluates rules against each part.\n\nThe dominant open rule set is the OWASP ModSecurity Core Rule Set (CRS), which runs on the ModSecurity engine, now an OWASP project, and on Coraza. CRS uses anomaly scoring by default: each matching rule adds points, typically 5 for a critical match, and the request is blocked only when the total exceeds a threshold, default 5 for inbound traffic. Paranoia levels 1 to 4 trade coverage against false positives, and production tuning consists largely of writing rule exclusions for specific parameters that legitimately contain SQL-like or HTML-like content. Commercial WAFs add bot detection, rate limiting, IP reputation, API schema enforcement and machine-learning classifiers on top of signatures.\n\nTwo security models are used. A negative model blocks known-bad patterns and is easy to deploy but can be bypassed; a positive model allows only what the application is known to accept, such as defined paths, methods, parameter types and lengths, often derived from an OpenAPI description, which is stronger but costly to maintain as the application changes. Known bypass classes include alternative encodings, case and comment tricks in SQL, HTTP parameter pollution, request smuggling where the WAF and back end disagree on message boundaries, payloads in content types the WAF does not parse, and oversized bodies beyond the inspection limit. In 2022 Claroty showed that several major WAFs could be bypassed with JSON-based SQL syntax because their parsers did not understand it.\n\nThe main legitimate use is virtual patching: blocking exploitation of a known vulnerability, such as Log4Shell in December 2021, while the fix is developed and deployed. PCI DSS v4.0 requirement 6.4.2, mandatory since 31 March 2025, requires an automated technical solution that continually detects and prevents web-based attacks in front of public-facing web applications, and a WAF is the usual way to meet it. A WAF cannot see business-logic flaws, broken object-level authorization, or stored payloads already inside the application, so it complements rather than replaces secure code.","da":"En WAF terminerer eller inspicerer HTTP(S)-trafik på lag 7, så den skal kunne se trafikken dekrypteret: enten terminerer den selv TLS som reverse proxy, kører som modul i webserveren eller ingress-controlleren eller leveres som cloud- eller CDN-tjeneste ved kanten. Den kan placeres inline og blokere, som transparent bro eller out-of-band på en kopi af trafikken, hvor den kun kan opdage, ikke blokere. Den opdeler forespørgslen i bestanddele som metode, URI, query-parametre, headers, cookies og en body dekodet som formulardata, JSON, XML eller multipart, normaliserer encodings og evaluerer regler mod hver del.\n\nDet dominerende åbne regelsæt er OWASP ModSecurity Core Rule Set (CRS), der kører på ModSecurity-motoren, som nu er et OWASP-projekt, og på Coraza. CRS bruger som standard anomaly scoring: hver regel, der rammer, giver point, typisk 5 for et kritisk match, og forespørgslen blokeres først, når summen overstiger en tærskel, som standard 5 for indgående trafik. Paranoia-niveau 1 til 4 afvejer dækning mod falske positiver, og tuning i produktion består i høj grad af at skrive undtagelser for bestemte parametre, der legitimt indeholder SQL- eller HTML-lignende indhold. Kommercielle WAF'er lægger bot-genkendelse, rate limiting, IP-omdømme, håndhævelse af API-skemaer og maskinlæringsklassifikatorer oven på signaturerne.\n\nDer bruges to sikkerhedsmodeller. En negativ model blokerer kendte farlige mønstre og er let at udrulle, men kan omgås; en positiv model tillader kun det, applikationen vides at acceptere, fx definerede stier, metoder, parametertyper og længder, ofte afledt af en OpenAPI-beskrivelse, hvilket er stærkere, men dyrt at vedligeholde, når applikationen ændrer sig. Kendte klasser af omgåelser er alternative encodings, tricks med store og små bogstaver og kommentarer i SQL, HTTP parameter pollution, request smuggling, hvor WAF og backend er uenige om, hvor en besked slutter, payloads i content types, WAF'en ikke parser, og for store bodies ud over inspektionsgrænsen. I 2022 viste Claroty, at flere store WAF'er kunne omgås med JSON-baseret SQL-syntaks, fordi deres parsere ikke forstod den.\n\nDen vigtigste legitime anvendelse er virtuel patching: at blokere udnyttelse af en kendt sårbarhed, som Log4Shell i december 2021, mens rettelsen udvikles og udrulles. PCI DSS v4.0 krav 6.4.2, der har været obligatorisk siden 31. marts 2025, kræver en automatiseret teknisk løsning, der løbende opdager og forhindrer webbaserede angreb foran offentligt tilgængelige webapplikationer, og en WAF er den almindelige måde at opfylde det på. En WAF kan ikke se fejl i forretningslogik, manglende autorisation på objektniveau eller lagrede payloads, der allerede ligger i applikationen, så den supplerer sikker kode uden at erstatte den."},"howTo":{"steps":{"en":["List the public web applications and APIs that need protection, and choose how to deploy the WAF, as a cloud or CDN service, a reverse proxy or a module in the web server or ingress controller.","Make sure the WAF sees decrypted traffic, and lock down the origin servers so they only accept traffic that has passed through the WAF.","Enable a managed rule set such as the OWASP Core Rule Set at its lowest paranoia level, and set limits on request body size and allowed content types.","Run in detection mode first and go through the logs to find rules that fire on legitimate traffic.","Write narrow exclusions for specific rules and parameters instead of turning off whole rule groups, and keep the configuration as code so it survives rule set upgrades.","Switch to prevention mode once false positives are under control, and add rate limits and bot rules for logins and other sensitive endpoints.","Send the WAF logs to the SIEM, and review blocked requests and attack trends regularly.","When a critical vulnerability hits one of your applications, add a virtual patch rule straight away, and remove it once the code has been fixed.","Keep the rule sets up to date, and retest with known attack payloads after every major change to the application or the rules."],"da":["Lav en liste over de offentlige webapplikationer og API'er, der skal beskyttes, og vælg, hvordan WAF'en skal køre, som cloud- eller CDN-tjeneste, som reverse proxy eller som modul i webserveren eller ingress-controlleren.","Sørg for, at WAF'en ser trafikken dekrypteret, og luk originserverne ned, så de kun tager imod trafik, der er gået gennem WAF'en.","Slå et administreret regelsæt som OWASP Core Rule Set til på laveste paranoia-niveau, og sæt grænser for body-størrelse og tilladte content types.","Kør først i detektionstilstand, og gennemgå logs for at finde regler, der rammer legitim trafik.","Skriv snævre undtagelser for bestemte regler og parametre i stedet for at slå hele regelgrupper fra, og hold konfigurationen som kode, så den overlever opgraderinger af regelsættet.","Skift til blokeringstilstand, når de falske positiver er under kontrol, og tilføj rate limits og bot-regler for login og andre følsomme endpoints.","Send WAF-logs til SIEM'en, og gennemgå jævnligt blokerede forespørgsler og udviklingen i angreb.","Når en kritisk sårbarhed rammer en af jeres applikationer, så tilføj straks en regel som virtuel patch, og fjern den, når koden er rettet.","Hold regelsættene opdaterede, og test igen med kendte angrebs-payloads efter hver større ændring af applikationen eller reglerne."]},"pitfalls":{"en":["Leaving the WAF in detection mode for months, so it logs attacks but blocks nothing.","Letting the origin server accept traffic directly, so attackers simply go around the WAF.","Turning off whole rule groups to silence false positives.","Treating the WAF as a substitute for fixing the code, although it cannot see business-logic or authorisation flaws."],"da":["At lade WAF'en stå i detektionstilstand i månedsvis, så den logger angreb, men ikke blokerer noget.","At lade originserveren tage imod trafik direkte, så angribere bare går uden om WAF'en.","At slå hele regelgrupper fra for at få de falske positiver til at forsvinde.","At se WAF'en som en erstatning for at rette koden, selv om den ikke kan se fejl i forretningslogik eller autorisation."]},"guides":[{"title":"OWASP CRS Documentation - False Positives and Tuning","url":"https://coreruleset.org/docs/2-how-crs-works/2-3-false-positives-and-tuning/","publisher":"OWASP","tier":"reference"},{"title":"OWASP Cheat Sheet Series - Virtual Patching","url":"https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html","publisher":"OWASP","tier":"reference"},{"title":"Best Practices for Azure Web Application Firewall (WAF) on Application Gateway","url":"https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/best-practices","publisher":"Microsoft","tier":"official-doc"}]},"edges":[{"type":"requires","to":"cs/http","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/web-application","confidence":"high","strength":"normal"},{"type":"kind-of","to":"cs/firewall","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/sql-injection","why":{"en":"Its rules spot and block requests that carry database commands in fields meant for plain text.","da":"Dens regler opdager og blokerer forespørgsler, der bærer databasekommandoer i felter beregnet til almindelig tekst."},"confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/cross-site-scripting","why":{"en":"It can block requests that try to plant a script, but it cannot see a script already stored in the site.","da":"Den kan blokere forespørgsler, der forsøger at plante et script, men den kan ikke se et script, der allerede ligger gemt på sitet."},"confidence":"medium","strength":"normal"}],"depth":6,"sources":[{"title":"OWASP - Web Application Firewall","url":"https://owasp.org/www-community/Web_Application_Firewall","tier":"reference","publisher":"OWASP"},{"title":"NIST SP 800-41 Rev. 1 - Guidelines on Firewalls and Firewall Policy","tier":"standard","publisher":"NIST"}],"draft":true}