{"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://cmaintz.github.io/tech-atlas/)"},"id":"security/input-validation","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/input-validation/","da":"https://cmaintz.github.io/tech-atlas/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."},"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}