{"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/input-validation","url":{"en":"https://atlas.maintz.dev/en/terms/security/input-validation/","da":"https://atlas.maintz.dev/da/terms/security/input-validation/"},"term":{"en":"Input validation","da":"Inputvalidering"},"aka":{"en":[],"da":[]},"domain":["security"],"cluster":"application-security","layer":"application","status":"current","summary":{"en":"Checking every piece of data a program receives against strict rules before using it, and turning away anything that does not fit.","da":"At tjekke alle data, et program modtager, mod faste regler, før de bruges, og afvise alt, der ikke passer."},"body":{"formal":{"en":"A control in which a program checks all data from outside - form fields, uploaded files, API calls - for expected type, length, format and range on the server side, preferring a list of what is allowed over a list of what is forbidden.","da":"En kontrol, hvor et program på serversiden tjekker alle data udefra - formularfelter, indsendte filer, API-kald - for forventet type, længde, format og værdiområde og hellere bruger en liste over det tilladte end en liste over det forbudte."},"plain":{"en":"Like a post office that only accepts parcels of set sizes with a proper address on them, and hands everything else straight back across the counter.","da":"Som et posthus, der kun tager imod pakker i bestemte størrelser med en ordentlig adresse på og straks giver alt andet tilbage over disken."},"inPractice":{"en":"A municipality's online form for parking permits accepts a postal code only if it is exactly four digits; a request with letters or symbols in that field is turned away before it reaches the database.","da":"En kommunes selvbetjeningsformular til parkeringstilladelser godtager kun et postnummer, hvis det er præcis fire cifre; en forespørgsel med bogstaver eller tegn i feltet afvises, før den når databasen."},"whyItMatters":{"en":"Most attacks on software start with input the developer did not expect; checking it at the door stops many of them early, though it must be backed by safe handling further in.","da":"De fleste angreb på software begynder med input, udvikleren ikke havde regnet med; et tjek ved døren stopper mange af dem tidligt, men det skal bakkes op af sikker håndtering længere inde."}},"deepDive":{"en":"The OWASP Input Validation Cheat Sheet distinguishes syntactic validation, which enforces the correct form of a value (a Danish CPR number is ten digits, a date parses as ISO 8601, a quantity is an integer), from semantic validation, which enforces correctness in the business context (a start date precedes the end date, a quantity is between 1 and 99, the referenced account belongs to the caller). Both should run on the server at the trust boundary, as early as possible, before the data reaches business logic or storage. Client-side checks improve usability but provide no security, because any HTTP client can bypass them. NIST SP 800-53 Rev. 5 captures the same control as SI-10 Information Input Validation, and the corresponding weakness is CWE-20 Improper Input Validation.\n\nAllowlisting defines what is acceptable, through a type, an enumeration, a length bound, a numeric range or an anchored regular expression, and rejects everything else. Denylisting known-bad strings such as script tags or SQL keywords is brittle: attackers bypass it with alternative encodings, case changes, comments and Unicode look-alikes. Input should be decoded and canonicalised (URL decoding, Unicode normalisation such as NFC or NFKC, path resolution) before it is validated, otherwise a check on \"../\" can be bypassed with %2e%2e%2f or overlong encodings. Regular expressions themselves can become a denial-of-service vector: patterns with nested quantifiers can backtrack catastrophically on crafted input (ReDoS), so length limits should be applied first.\n\nStructured inputs are best validated against a schema: JSON Schema or OpenAPI for API bodies, XSD for XML with DTDs and external entities disabled to prevent XXE, and strict binding to explicit data-transfer objects so extra properties are rejected, which also prevents mass assignment. File uploads need a size limit, an allowlist of extensions checked together with the actual content signature rather than the client-supplied Content-Type, server-generated file names and storage outside the web root.\n\nThe most important limitation is that validation is not a substitute for context-specific output handling. A string can be perfectly valid, such as the surname O'Neil or a free-text comment containing angle brackets, and still be dangerous in a SQL statement or an HTML page. Injection is prevented at the point of use through parameterised queries, contextual output encoding and safe APIs; validation reduces the attack surface and catches malformed data early. The same applies to data from internal services, databases and LLM outputs, which should be treated as untrusted when they originate outside the component's own control.","da":"OWASP's Input Validation Cheat Sheet skelner mellem syntaktisk validering, der håndhæver en værdis korrekte form (et CPR-nummer er ti cifre, en dato kan parses som ISO 8601, et antal er et heltal), og semantisk validering, der håndhæver korrekthed i forretningskonteksten (en startdato ligger før slutdatoen, et antal er mellem 1 og 99, den konto, der henvises til, tilhører kalderen). Begge dele skal køre på serveren ved tillidsgrænsen, så tidligt som muligt, før data når forretningslogik eller lagring. Tjek i klienten forbedrer brugeroplevelsen, men giver ingen sikkerhed, fordi enhver HTTP-klient kan gå uden om dem. NIST SP 800-53 Rev. 5 beskriver samme kontrol som SI-10 Information Input Validation, og den tilsvarende svaghed er CWE-20 Improper Input Validation.\n\nAllowlisting definerer, hvad der er acceptabelt, via en type, en opremsning af gyldige værdier, en længdegrænse, et talinterval eller et forankret regulært udtryk, og afviser alt andet. Denylisting af kendte farlige strenge som script-tags eller SQL-nøgleord er skrøbeligt: angribere omgår det med alternative encodings, skift mellem store og små bogstaver, kommentarer og Unicode-tegn, der ligner andre tegn. Input skal dekodes og kanoniseres (URL-dekodning, Unicode-normalisering som NFC eller NFKC, opløsning af stier), før det valideres, ellers kan et tjek for \"../\" omgås med %2e%2e%2f eller overlange encodings. Regulære udtryk kan selv blive en vej til denial of service: mønstre med indlejrede kvantorer kan backtracke katastrofalt på udformet input (ReDoS), så længdegrænser skal anvendes først.\n\nStruktureret input valideres bedst mod et skema: JSON Schema eller OpenAPI for API-bodies, XSD for XML med DTD'er og eksterne entiteter slået fra for at undgå XXE, og streng binding til eksplicitte dataoverførselsobjekter, så ekstra felter afvises, hvilket også forhindrer mass assignment. Filuploads kræver en størrelsesgrænse, en allowlist over filtyper, der tjekkes sammen med filens faktiske signatur frem for den Content-Type, klienten oplyser, filnavne genereret af serveren og lagring uden for webroden.\n\nDen vigtigste begrænsning er, at validering ikke erstatter håndtering tilpasset den kontekst, data bruges i. En streng kan være fuldt gyldig, fx efternavnet O'Neil eller en fritekstkommentar med vinkelparenteser, og alligevel være farlig i en SQL-sætning eller på en HTML-side. Injection forhindres dér, hvor data bruges, med parameteriserede forespørgsler, kontekstafhængig output-encoding og sikre API'er; validering gør angrebsfladen mindre og fanger fejlformede data tidligt. Det samme gælder data fra interne tjenester, databaser og output fra sprogmodeller, som skal behandles som ubetroede, når de stammer fra noget uden for komponentens egen kontrol."},"howTo":{"steps":{"en":["Map every trust boundary where data enters the application, including form fields, query parameters, headers, cookies, API bodies, files, queue messages and replies from other services or language models.","Write down the allowed type, length, format and range for each field, and keep the rules in shared validators or a JSON Schema or OpenAPI description rather than scattered through the code.","Decode and normalise input, for example URL decoding and Unicode normalisation, before you validate it, so encoded variants cannot slip past the check.","Validate on the server at the boundary, first the syntax and then the business meaning, and reject input that does not fit instead of trying to repair it.","Bind structured input to explicit objects that reject unknown properties, and configure XML parsers with DTDs and external entities turned off.","For file uploads, check the size, an allowlist of extensions and the real file signature, give each file a server-generated name and store it outside the web root.","Keep the defences at the point of use as well, with parameterised queries, contextual output encoding and safe APIs.","Log rejected input safely, without echoing it back unescaped, and add unit tests and fuzz tests for the validators to the build pipeline."],"da":["Kortlæg alle tillidsgrænser, hvor data kommer ind i applikationen, herunder formularfelter, query-parametre, headers, cookies, API-bodies, filer, beskeder fra køer og svar fra andre tjenester eller sprogmodeller.","Skriv for hvert felt den tilladte type, længde, format og værdiområde ned, og saml reglerne i fælles validatorer eller en JSON Schema- eller OpenAPI-beskrivelse i stedet for at sprede dem ud i koden.","Dekod og normalisér input, fx URL-dekodning og Unicode-normalisering, før det valideres, så kodede varianter ikke kan snige sig forbi tjekket.","Validér på serveren ved grænsen, først syntaksen og derefter den forretningsmæssige betydning, og afvis input, der ikke passer, i stedet for at forsøge at rette det.","Bind struktureret input til eksplicitte objekter, der afviser ukendte felter, og konfigurér XML-parsere med DTD'er og eksterne entiteter slået fra.","Ved filupload skal I tjekke størrelse, en allowlist over filtyper og filens faktiske signatur, give hver fil et navn genereret af serveren og gemme den uden for webroden.","Behold også forsvaret dér, hvor data bruges, med parameteriserede forespørgsler, kontekstafhængig output-encoding og sikre API'er.","Log afvist input sikkert uden at sende det uescaped tilbage, og læg unit tests og fuzz tests af validatorerne ind i build-pipelinen."]},"pitfalls":{"en":["Validating only in the browser, which any HTTP client can bypass.","Relying on denylists of known bad strings, which alternative encodings and case tricks get around.","Treating validation as the fix for SQL injection or XSS instead of parameterised queries and output encoding.","Writing regular expressions with nested quantifiers and no length limit, which opens the door to ReDoS."],"da":["Kun at validere i browseren, hvilket enhver HTTP-klient kan gå uden om.","At stole på denylists over kendte farlige strenge, som alternative encodings og tricks med store og små bogstaver kommer uden om.","At se validering som løsningen på SQL injection eller XSS i stedet for parameteriserede forespørgsler og output-encoding.","At skrive regulære udtryk med indlejrede kvantorer og uden længdegrænse, hvilket åbner for ReDoS."]},"guides":[{"title":"OWASP Cheat Sheet Series - Input Validation","url":"https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html","publisher":"OWASP","tier":"reference"},{"title":"OWASP Top 10 Proactive Controls - C3 Validate all Input and Handle Exceptions","url":"https://top10proactive.owasp.org/archive/2024/the-top-10/c3-validate-input-and-handle-exceptions/","publisher":"OWASP","tier":"reference"},{"title":"OWASP Cheat Sheet Series - File Upload","url":"https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html","publisher":"OWASP","tier":"reference"},{"title":"CWE-20 - Improper Input Validation","url":"https://cwe.mitre.org/data/definitions/20.html","publisher":"MITRE","tier":"reference"}]},"edges":[{"type":"kind-of","to":"security/control","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/sql-injection","why":{"en":"Strict rules on what a field may hold stop most crafted commands, though keeping input apart from the command itself remains the main defence.","da":"Faste regler for, hvad et felt må indeholde, stopper de fleste udformede kommandoer, men at holde input adskilt fra selve kommandoen er stadig det vigtigste forsvar."},"confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/cross-site-scripting","why":{"en":"Rejecting unexpected characters helps, but the main defence is making data harmless at the moment it is placed in a page.","da":"At afvise uventede tegn hjælper, men det vigtigste forsvar er at gøre data ufarlige i det øjeblik, de sættes ind på en side."},"confidence":"high","strength":"minor"},{"type":"used-with","to":"security/web-application-firewall","why":{"en":"The WAF filters known attack patterns before they arrive; validation in the code checks what each field should hold.","da":"WAF'en filtrerer kendte angrebsmønstre, før de når frem; validering i koden tjekker, hvad hvert felt skal indeholde."},"confidence":"high","strength":"normal"},{"type":"used-with","to":"ai/structured-output","why":{"en":"A reply in the right shape can still hold wrong or harmful values, so code must check it like any input it cannot trust.","da":"Et svar i den rigtige form kan stadig indeholde forkerte eller skadelige værdier, så kode skal validere det som ethvert input, man ikke kan stole på."},"confidence":"medium","strength":"normal"}],"depth":0,"sources":[{"title":"OWASP Cheat Sheet Series - Input Validation","url":"https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html","tier":"reference","publisher":"OWASP"},{"title":"NIST SP 800-53 Rev. 5 - SI-10 Information Input Validation","tier":"standard","publisher":"NIST"}],"draft":true}