40 lines
1.1 KiB
Org Mode
40 lines
1.1 KiB
Org Mode
:PROPERTIES:
|
|
:ID: 05698e38-65b2-496c-b02b-1db376ae734c
|
|
:END:
|
|
#+title: Validation vs Sanitization
|
|
|
|
There are distinct factors that go into deciding whether to [[id:9914d09e-99fe-46a6-95be-676c5b78ed90][validate input]]
|
|
(rejecting unwanted data) or to [[id:2ba04972-f498-41c2-970e-a64c7f3f1c3b][sanitize input]] (accept and alter data).
|
|
|
|
Commonly, data is validated on input, and sanitized when it is displayed:
|
|
|
|
#+begin_src plantuml :file validation-and-sanitization.svg
|
|
cloud "Input" as input
|
|
component API {
|
|
interface POST
|
|
usecase "Validate input" as validate
|
|
database "Data store" as data
|
|
interface GET
|
|
}
|
|
frame Client {
|
|
usecase "Sanitize and display" as sanitize
|
|
file "Output" as output
|
|
}
|
|
|
|
input -> POST
|
|
POST -> validate
|
|
validate -> data
|
|
data -> GET
|
|
GET -> sanitize
|
|
sanitize -> output
|
|
|
|
#+end_src
|
|
|
|
#+RESULTS:
|
|
[[file:validation-and-sanitization.svg]]
|
|
|
|
This has the following benefits:
|
|
- Input that is accepted correctly matches the types and constraints of its
|
|
domain.
|
|
- The client is soley responsible for ensuring that data is displayed correctly
|
|
and securely.
|