Input Validation and Sanitization

21 min read

Every byte that crosses a trust boundary — an HTTP body, a query string, a CLI flag, a file — is hostile until proven otherwise. This page is about turning that untrusted input into trustworthy values, the Rust way: parse, don’t validate, push the rules into the type system, and reach for the validator crate when you want declarative field-level checks.

Note: Validation is the foundation of the rest of this section. Validated input still needs safe handling downstream: see SQL injection prevention for the database boundary and XSS and CSRF protection for the HTML/browser boundary. Validation is necessary but never sufficient.

Quick Overview

Input validation answers one question: can I trust this data enough to act on it? In TypeScript you typically reach for a runtime schema library (Zod, Yup, io-ts) because TypeScript types are erased at runtime and cannot check anything about real values. Rust keeps its types at runtime through monomorphization, so the most powerful technique is to encode the rules in a type — once you hold a Email or a Quantity, it is guaranteed valid, and the compiler stops you from forgetting to check. This is the “parse, don’t validate” philosophy, and it eliminates a whole class of “I forgot to check that field” bugs that no amount of code review reliably catches.

TypeScript/JavaScript Example

A realistic signup endpoint. TypeScript’s compile-time types tell you nothing about the JSON that actually arrives, so you bolt on a runtime schema with Zod (v4):

1
// npm install zod  (zod v4)
2
import { z } from "zod";
3

4
const SignupSchema = z.object({
5
  username: z.string().min(3).max(20),
6
  email: z.email(),
7
  age: z.number().int().min(18).max(120),
8
});
9

10
// The *inferred* type — but it only exists at compile time.
11
type Signup = z.infer<typeof SignupSchema>;
12

13
function handleSignup(body: unknown) {
14
  const result = SignupSchema.safeParse(body);
15
  if (!result.success) {
16
    for (const issue of result.error.issues) {
17
      console.log(issue.path.join("."), "-", issue.message);
18
    }
19
    return { status: 422 };
20
  }
21
  // result.data is now typed as Signup AND validated.
22
  const user: Signup = result.data;
23
  return { status: 201, user };
24
}
25

26
handleSignup({ username: "ab", email: "nope", age: 12 });

Running this against Node v22 with zod 4.4.3 prints:

1
username - Too small: expected string to have >=3 characters
2
email - Invalid email address
3
age - Too small: expected number to be >=18

Key points:

z.infer derives a compile-time type from the schema, but the schema object is what does the real work at runtime.
Nothing in the type system forces you to call safeParse. You can write body as Signup and skip validation entirely — the cast compiles, and the bug ships.
The validated result.data is a plain object; it is structurally identical to an unvalidated one, so once it leaves this function the “it’s been validated” guarantee lives only in your head.

Rust Equivalent

Rust gives you two complementary tools. First, the type-driven approach — make an invalid value unrepresentable by parsing into a dedicated type whose constructor is the only way in:

1
use std::fmt;
2

3
/// A validated username. If you hold one, it is guaranteed to satisfy the rules.
4
#[derive(Debug, Clone)]
5
struct Username(String);
6

7
#[derive(Debug)]
8
enum UsernameError {
9
    TooShort,
10
    TooLong,
11
    InvalidChar(char),
12
}
13

14
impl fmt::Display for UsernameError {
15
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
16
        match self {
17
            UsernameError::TooShort => write!(f, "username must be at least 3 characters"),
18
            UsernameError::TooLong => write!(f, "username must be at most 20 characters"),
19
            UsernameError::InvalidChar(c) => write!(f, "invalid character: {c:?}"),
20
        }
21
    }
22
}
23
impl std::error::Error for UsernameError {}
24

25
impl Username {
26
    /// The *only* way to build a `Username`. Validation happens here, once.
27
    fn parse(raw: &str) -> Result<Self, UsernameError> {
28
        let trimmed = raw.trim();
29
        let len = trimmed.chars().count();
30
        if len < 3 {
31
            return Err(UsernameError::TooShort);
32
        }
33
        if len > 20 {
34
            return Err(UsernameError::TooLong);
35
        }
36
        if let Some(bad) = trimmed
37
            .chars()
38
            .find(|c| !(c.is_ascii_alphanumeric() || *c == '_'))
39
        {
40
            return Err(UsernameError::InvalidChar(bad));
41
        }
42
        Ok(Username(trimmed.to_string()))
43
    }
44

45
    fn as_str(&self) -> &str {
46
        &self.0
47
    }
48
}
49

50
fn main() {
51
    for raw in ["  alice_99  ", "hi", "no spaces!"] {
52
        match Username::parse(raw) {
53
            Ok(u) => println!("ok: {:?} -> {:?}", raw, u.as_str()),
54
            Err(e) => println!("rejected {:?}: {e}", raw),
55
        }
56
    }
57
}

Real output:

1
ok: "  alice_99  " -> "alice_99"
2
rejected "hi": username must be at least 3 characters
3
rejected "no spaces!": invalid character: ' '

Second, the declarative approach — the validator crate, which feels closest to Zod. Add the dependency:

1
cargo add validator --features derive
2
cargo add serde --features derive
3
cargo add serde_json

1
use serde::Deserialize;
2
use validator::Validate;
3

4
#[derive(Debug, Deserialize, Validate)]
5
struct SignupForm {
6
    #[validate(length(min = 3, max = 20, message = "username must be 3-20 chars"))]
7
    username: String,
8

9
    #[validate(email(message = "must be a valid email address"))]
10
    email: String,
11

12
    #[validate(length(min = 8, message = "password must be at least 8 chars"))]
13
    password: String,
14

15
    #[validate(range(min = 18, max = 120, message = "age must be between 18 and 120"))]
16
    age: u8,
17
}
18

19
fn main() {
20
    let raw = r#"
21
    {
22
        "username": "ab",
23
        "email": "not-an-email",
24
        "password": "short",
25
        "age": 12
26
    }"#;
27

28
    // serde_json checks the *shape* (types, presence); validator checks the *values*.
29
    let form: SignupForm = serde_json::from_str(raw).expect("valid JSON shape");
30

31
    match form.validate() {
32
        Ok(()) => println!("all fields valid"),
33
        Err(errors) => {
34
            for (field, errs) in errors.field_errors() {
35
                for e in errs {
36
                    let msg = e
37
                        .message
38
                        .as_ref()
39
                        .map(|m| m.to_string())
40
                        .unwrap_or_else(|| e.code.to_string());
41
                    println!("{field}: {msg}");
42
                }
43
            }
44
        }
45
    }
46
}

Real output (field order is not deterministic — field_errors returns a map):

1
password: password must be at least 8 chars
2
age: age must be between 18 and 120
3
username: username must be 3-20 chars
4
email: must be a valid email address

Key points:

The Username newtype makes “unvalidated username” a different type from “validated username”. You cannot accidentally pass the wrong one — the compiler rejects it.
The validator derive mirrors Zod’s declarative feel: attributes describe constraints, .validate() runs them.
serde deserialization already enforced the shape (an age of "twelve" fails before validate() ever runs); validator enforces the business rules on top.

Detailed Explanation

”Parse, don’t validate”

The phrase comes from Alexis King’s well-known essay, and Rust is the language where it shines. The idea: a validator is a function (input) -> bool that throws away its findings — after isValidEmail(s) returns true, you still hold a plain string, and the next function has no idea it was checked. A parser is a function (input) -> Result<Parsed, Error> that returns a new type carrying the proof. Once you hold an Email, the fact that it is well-formed is encoded in the type, not in a comment or a convention.

In the Username::parse example, look at what the type system now guarantees:

There is no public way to build a Username except parse. (We will tighten this with module privacy in the next subsection.)
Every function that accepts &Username can assume the rules hold — no re-checking, no defensive if.
If you refactor and add a new call site, you cannot forget to validate, because you literally cannot produce the value without going through parse.

Contrast this with the Zod version: result.data and an unchecked body as Signup have the exact same type. The “validated” property is invisible to the compiler, so the only thing stopping an unvalidated object from flowing downstream is your discipline.

Type-driven validation with newtypes

A newtype is a single-field tuple struct (struct Email(String)) that wraps an existing type to give it new meaning and new guarantees. (Sections 02-basics/01_types.md and the data-structures section cover the mechanics; here we use them for safety.) The key move is field privacy: keep the inner field private so outside code must use your constructor.

You can also parse directly at the deserialization boundary by implementing Deserialize for the newtype. Now invalid JSON never even produces a value of your type — the failure happens inside serde_json::from_str:

1
use serde::{Deserialize, Deserializer};
2

3
/// A validated email address. Holding one proves it is well-formed.
4
#[derive(Debug, Clone)]
5
struct Email(String);
6

7
impl Email {
8
    fn parse(raw: &str) -> Result<Self, String> {
9
        let raw = raw.trim();
10
        // Deliberately simple structural check for the example.
11
        let (local, domain) = raw
12
            .split_once('@')
13
            .ok_or_else(|| "email must contain '@'".to_string())?;
14
        if local.is_empty() || domain.is_empty() || !domain.contains('.') {
15
            return Err("email is not well-formed".to_string());
16
        }
17
        Ok(Email(raw.to_lowercase()))
18
    }
19
    fn as_str(&self) -> &str {
20
        &self.0
21
    }
22
}
23

24
// Deserialize straight into the parsed type: invalid input is rejected by serde itself.
25
impl<'de> Deserialize<'de> for Email {
26
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
27
    where
28
        D: Deserializer<'de>,
29
    {
30
        let raw = String::deserialize(deserializer)?;
31
        Email::parse(&raw).map_err(serde::de::Error::custom)
32
    }
33
}
34

35
#[derive(Debug, Deserialize)]
36
struct Contact {
37
    name: String,
38
    email: Email,
39
}
40

41
fn main() {
42
    let good = r#"{ "name": "Bob", "email": "BOB@Example.COM " }"#;
43
    let bad = r#"{ "name": "Bob", "email": "not-an-email" }"#;
44

45
    match serde_json::from_str::<Contact>(good) {
46
        Ok(c) => println!("parsed: {} <{}>", c.name, c.email.as_str()),
47
        Err(e) => println!("error: {e}"),
48
    }
49
    match serde_json::from_str::<Contact>(bad) {
50
        Ok(c) => println!("parsed: {} <{}>", c.name, c.email.as_str()),
51
        Err(e) => println!("error: {e}"),
52
    }
53
}

Real output:

1
parsed: Bob <bob@example.com>
2
error: email must contain '@' at line 1 column 42

Notice that the constructor also normalized the value (trimmed whitespace, lowercased the address). Parsing is the natural place to canonicalize input, so every Email you hold downstream is not just valid but in one consistent form — which is exactly what you want before storing it or comparing it.

Declarative validation with the `validator` crate

The newtype approach is the strongest guarantee, but it is verbose when a request has a dozen fields, each with simple length/range/format rules. That is where validator earns its place. It generates a validate(&self) -> Result<(), ValidationErrors> method from attributes. Built-in validators include length, range, email, url, contains, does_not_contain, must_match, regex, and custom.

Two rules to internalize:

serde runs first and enforces structure: required fields, correct JSON types, no unexpected nulls. If the JSON shape is wrong, from_str fails and validate() never runs.
validator runs second (you must call it explicitly) and enforces value-level business rules.

For rules the built-ins do not cover, write a custom function. It receives the field value and returns Result<(), ValidationError>. You can also enforce cross-field rules like “passwords must match”:

1
use serde::Deserialize;
2
use validator::{Validate, ValidationError};
3

4
fn validate_no_spaces(value: &str) -> Result<(), ValidationError> {
5
    if value.contains(' ') {
6
        return Err(ValidationError::new("contains_space"));
7
    }
8
    Ok(())
9
}
10

11
#[derive(Debug, Deserialize, Validate)]
12
struct CreateUser {
13
    #[validate(length(min = 3, max = 20), custom(function = "validate_no_spaces"))]
14
    username: String,
15
    #[validate(email)]
16
    email: String,
17
    #[validate(must_match(other = "password"))]
18
    password_confirm: String,
19
    #[validate(length(min = 8))]
20
    password: String,
21
}
22

23
fn main() {
24
    let body = CreateUser {
25
        username: "bad name".into(),
26
        email: "x@y.com".into(),
27
        password: "longenough".into(),
28
        password_confirm: "different".into(),
29
    };
30
    match body.validate() {
31
        Ok(()) => println!("valid"),
32
        Err(e) => println!("{e}"), // ValidationErrors has a flat Display impl
33
    }
34
}

Real output:

1
username: Validation error: contains_space [{"value": String("bad name")}]
2
password_confirm: Validation error: must_match [{"value": String("different"), "other": String("longenough")}]

The raw Display output is developer-facing and leaks internal codes; in a real API you would map ValidationErrors into a clean response shape, as shown in the Real-World Example below.

Tip: validator and newtypes compose. Use validator for the broad sweep of simple field rules on a request DTO, then convert that DTO into a domain struct made of newtypes (Email, Username, Quantity) so the rest of your codebase works only with already-proven values. The DTO is the airlock; the domain types are the clean room.

Key Differences

Concern	TypeScript (Zod/Yup)	Rust
When do types exist?	Compile time only — erased at runtime	Runtime — types are monomorphized and real
What enforces validation?	A library call you must remember to make	The library call or the type system itself (newtypes)
Can you skip validation?	Yes — `body as T` casts compile silently	With newtypes, no — there is no other constructor
Shape vs. value checks	One library (Zod) does both	`serde` checks shape; `validator`/newtypes check values
”Validated” is visible to the compiler?	No — `data` and unchecked object share a type	Yes — `Email` and `String` are different types
Normalization (trim/lowercase)	Manual, easy to forget	Naturally lives in the parsing constructor
Default safety posture	Opt-in; forgetting = silent bug	Opt-in for `validator`; enforced for newtypes

The deep difference: in TypeScript, validation is a runtime gate you bolt on because the type system already gave up at runtime. In Rust, validation can be a property the type system carries forever, so “is this validated?” becomes a compile-time question the compiler answers for you.

Warning: “Unlike TypeScript,” a Rust newtype is a genuine type boundary, not a type alias. type UserId = string in TypeScript is interchangeable with any other string; struct UserId(String) in Rust is not interchangeable with String or with struct OrderId(String). The branded-type pattern in TypeScript tries to emulate this with phantom intersection types, but it is still erased and bypassable.

Common Pitfalls

Pitfall 1: Believing a TypeScript type validates anything at runtime

A TS dev’s instinct is “the handler is typed (body: Signup), so body is a valid Signup.” It is not. The type was erased; body is whatever JSON arrived. The Rust analog of that mistake is trusting a #[derive(Deserialize)] struct without calling validate() — serde checked the shape but not the rules. Always run value-level validation, or deserialize into newtypes that validate themselves.

Pitfall 2: Making the newtype field public (or forgetting module privacy)

The whole point of a validating newtype is that its constructor is the only door in. If you write struct Email(pub String), or define the type and its caller in the same module, callers can build an invalid one directly. Keep the field private and put the type in its own module. The compiler then enforces the rule. Trying to skip the constructor produces a real error:

1
mod domain {
2
    pub struct Email(String); // field is private to the module
3

4
    impl Email {
5
        pub fn parse(raw: &str) -> Result<Self, String> {
6
            if raw.contains('@') {
7
                Ok(Email(raw.to_string()))
8
            } else {
9
                Err("bad email".into())
10
            }
11
        }
12
    }
13
}
14

15
fn main() {
16
    // does not compile (error[E0603]): tries to bypass the validating constructor
17
    let e = domain::Email("not-an-email".to_string());
18
    let _ = e;
19
}

The exact compiler error:

1
error[E0603]: tuple struct constructor `Email` is private
2
  --> src/main.rs:17:21
3
   |
4
 2 |     pub struct Email(String); // field is private to the module
5
   |                      ------ a constructor is private if any of the fields is private
6
...
7
17 |     let e = domain::Email("not-an-email".to_string());
8
   |                     ^^^^^ private tuple struct constructor
9
   |
10
note: the tuple struct constructor `Email` is defined here
11
  --> src/main.rs:2:5
12
   |
13
 2 |     pub struct Email(String);
14
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^

This error is a feature: the type system is refusing to let you create an unvalidated value. That is the safety you are paying for.

Pitfall 3: Validating but not normalizing

Two inputs can both be “valid” yet not equal: "Bob@Example.com " and "bob@example.com". If you validate without canonicalizing, you get duplicate accounts, case-sensitive lookups that miss, and inconsistent stored data. Do trimming, case-folding, and Unicode normalization inside the parsing constructor so every value you hold is already in canonical form.

Pitfall 4: Trusting client-side validation

A TS frontend often validates a form before submitting. That is a UX nicety, never a security control — an attacker calls your API directly with curl. Server-side validation is mandatory and independent. This is the same posture you bring to Rust: validate at the edge of every service, on every request, regardless of what the caller claims to have done.

Pitfall 5: Using overly clever regexes for structured formats

Reaching for a giant regex to validate emails, URLs, or dates is a classic trap (and a denial-of-service risk via catastrophic backtracking). Prefer the email/url validators, or purpose-built parsers (the url crate, time/chrono for dates). If you do use the regex crate, note it is linear-time by design and cannot catastrophically backtrack — but it still should not be your tool for parsing structured data when a real parser exists.

Best Practices

Validate at the boundary, once. Parse untrusted input into trusted types as early as possible — ideally in the deserialization/extractor layer — and let the rest of the code work only with proven values.
Prefer parsing over validating. When a rule matters to your domain (an email, a non-empty cart, a percentage 0–100), make a newtype. Make illegal states unrepresentable instead of re-checking them everywhere.
Keep newtype fields private and expose a parse/try_from/new constructor. Implement Deserialize (or TryFrom) so the type validates itself at the edge.
Let serde do shape, validator do values. Do not hand-roll presence/type checks that serde already gives you for free.
Normalize during parsing. Trim, lowercase, and Unicode-normalize so stored and compared values are canonical.
Bound everything. Cap string lengths, collection sizes, and numeric ranges. Unbounded input is a memory-exhaustion vector; pair this with body-size limits at the web layer (see ../28-production/README.md).
Return structured, non-leaky errors. Map validation failures to a clean 422-style response with field-keyed messages; never echo internal error codes or the raw input back verbatim.
Validation is not the end of safety. A validated string is still untrusted SQL and untrusted HTML. Always parameterize queries (SQL injection prevention) and encode output (XSS and CSRF protection).

Real-World Example

A production-flavored axum endpoint with a reusable ValidatedJson<T> extractor. It deserializes the body (shape check), runs validate() (value check), and short-circuits with a clean JSON 422 on failure — so every handler that uses it receives an already-valid payload. The current stable toolchain is Rust 1.96.0 on the 2024 edition, and cargo new selects it automatically.

1
cargo new signup-api && cd signup-api
2
cargo add axum
3
cargo add tokio --features full
4
cargo add serde --features derive
5
cargo add serde_json
6
cargo add validator --features derive

1
use axum::{
2
    extract::{rejection::JsonRejection, FromRequest, Request},
3
    http::StatusCode,
4
    response::{IntoResponse, Response},
5
    routing::post,
6
    Json, Router,
7
};
8
use serde::Deserialize;
9
use serde_json::json;
10
use validator::Validate;
11

12
/// A reusable extractor: deserialize JSON, then run validation.
13
/// On any failure it short-circuits before the handler body runs.
14
struct ValidatedJson<T>(T);
15

16
impl<S, T> FromRequest<S> for ValidatedJson<T>
17
where
18
    S: Send + Sync,
19
    T: for<'de> Deserialize<'de> + Validate,
20
{
21
    type Rejection = Response;
22

23
    async fn from_request(req: Request, state: &S) -> Result<Self, Self::Rejection> {
24
        // Step 1: shape check (serde). A bad JSON shape -> 400.
25
        let Json(value) = Json::<T>::from_request(req, state)
26
            .await
27
            .map_err(|err: JsonRejection| {
28
                (StatusCode::BAD_REQUEST, Json(json!({ "error": err.body_text() })))
29
                    .into_response()
30
            })?;
31

32
        // Step 2: value check (validator). A bad value -> 422.
33
        value.validate().map_err(|errs| {
34
            (
35
                StatusCode::UNPROCESSABLE_ENTITY,
36
                Json(json!({ "error": "validation failed", "fields": errs.to_string() })),
37
            )
38
                .into_response()
39
        })?;
40

41
        Ok(ValidatedJson(value))
42
    }
43
}
44

45
#[derive(Debug, Deserialize, Validate)]
46
struct CreateUser {
47
    #[validate(length(min = 3, max = 20))]
48
    username: String,
49
    #[validate(email)]
50
    email: String,
51
    #[validate(length(min = 8))]
52
    password: String,
53
}
54

55
// By the time this runs, `payload` is structurally valid — no defensive checks needed.
56
async fn create_user(ValidatedJson(payload): ValidatedJson<CreateUser>) -> impl IntoResponse {
57
    (
58
        StatusCode::CREATED,
59
        Json(json!({ "username": payload.username, "email": payload.email })),
60
    )
61
}
62

63
#[tokio::main]
64
async fn main() {
65
    let app: Router = Router::new().route("/users", post(create_user));
66

67
    let listener = tokio::net::TcpListener::bind("127.0.0.1:3000")
68
        .await
69
        .unwrap();
70
    println!("listening on {}", listener.local_addr().unwrap());
71
    axum::serve(listener, app).await.unwrap();
72
}

This compiles cleanly with axum 0.8 and passes cargo clippy with no warnings. The pattern is the Rust equivalent of a validating middleware in Express, but with a crucial upgrade: the handler’s type signature (ValidatedJson<CreateUser>) makes the validation contract part of the function, so a handler simply cannot run on unvalidated input. Note the current axum idioms in use: axum::serve(listener, app) (not the old Server::bind().serve()), and {id}-style route placeholders if you add path parameters.

Note: For an even stronger guarantee, have CreateUser deserialize its fields into newtypes (Username, Email) so validity is carried by the type all the way into your service layer, and validator becomes a convenience rather than the only line of defense.

Exercises

Exercise 1: A self-normalizing `Slug` newtype

Difficulty: Beginner

Objective: Practice the parse-don’t-validate pattern with normalization.

Instructions: Create a Slug newtype that wraps a String. Its parse(&str) -> Result<Slug, String> constructor should: trim whitespace, lowercase the input, reject an empty result, and reject any character that is not a-z, 0-9, or -. Keep the inner field private and expose as_str(&self) -> &str. Show that " Hello-World " parses to "hello-world" and that "bad slug!" is rejected.

Solution

1
#[derive(Debug, Clone)]
2
struct Slug(String);
3

4
impl Slug {
5
    fn parse(raw: &str) -> Result<Self, String> {
6
        let normalized = raw.trim().to_lowercase();
7
        if normalized.is_empty() {
8
            return Err("slug must not be empty".to_string());
9
        }
10
        if let Some(bad) = normalized
11
            .chars()
12
            .find(|c| !(c.is_ascii_lowercase() || c.is_ascii_digit() || *c == '-'))
13
        {
14
            return Err(format!("invalid character in slug: {bad:?}"));
15
        }
16
        Ok(Slug(normalized))
17
    }
18

19
    fn as_str(&self) -> &str {
20
        &self.0
21
    }
22
}
23

24
fn main() {
25
    match Slug::parse("  Hello-World  ") {
26
        Ok(s) => println!("ok: {:?}", s.as_str()),
27
        Err(e) => println!("rejected: {e}"),
28
    }
29
    match Slug::parse("bad slug!") {
30
        Ok(s) => println!("ok: {:?}", s.as_str()),
31
        Err(e) => println!("rejected: {e}"),
32
    }
33
}

Output:

1
ok: "hello-world"
2
rejected: invalid character in slug: ' '

Exercise 2: A `validator`-based DTO with a custom rule

Difficulty: Intermediate

Objective: Combine built-in and custom validator rules on a deserialized struct.

Instructions: Define a ProductForm with fields name: String (length 1–100), price_cents: u32 (range 1–1_000_000), and sku: String. Write a custom validator that requires sku to be exactly 8 ASCII-uppercase-alphanumeric characters. Deserialize a JSON body that violates the SKU rule and print the field errors. Add the dependencies with cargo add validator --features derive, cargo add serde --features derive, and cargo add serde_json.

Solution

1
use serde::Deserialize;
2
use validator::{Validate, ValidationError};
3

4
fn validate_sku(sku: &str) -> Result<(), ValidationError> {
5
    let ok = sku.len() == 8
6
        && sku.chars().all(|c| c.is_ascii_uppercase() || c.is_ascii_digit());
7
    if ok {
8
        Ok(())
9
    } else {
10
        Err(ValidationError::new("invalid_sku"))
11
    }
12
}
13

14
#[derive(Debug, Deserialize, Validate)]
15
struct ProductForm {
16
    #[validate(length(min = 1, max = 100))]
17
    name: String,
18
    #[validate(range(min = 1, max = 1_000_000))]
19
    price_cents: u32,
20
    #[validate(custom(function = "validate_sku"))]
21
    sku: String,
22
}
23

24
fn main() {
25
    let body = r#"
26
    {
27
        "name": "Wireless Mouse",
28
        "price_cents": 2499,
29
        "sku": "abc-123"
30
    }"#;
31

32
    let form: ProductForm = serde_json::from_str(body).expect("valid JSON shape");
33

34
    match form.validate() {
35
        Ok(()) => println!("valid"),
36
        Err(errors) => {
37
            for (field, errs) in errors.field_errors() {
38
                for e in errs {
39
                    println!("{field}: {}", e.code);
40
                }
41
            }
42
        }
43
    }
44
}

Output:

1
sku: invalid_sku

Exercise 3: Deserialize directly into a validated newtype

Difficulty: Advanced

Objective: Push validation into the serde boundary so invalid input can never construct your type.

Instructions: Create a Percentage newtype wrapping an f64 constrained to the inclusive range 0.0..=100.0. Implement Deserialize for it so that a JSON number outside the range fails inside serde_json::from_str (use serde::de::Error::custom). Embed it in a struct Discount { label: String, amount: Percentage }. Show that 42.5 succeeds and 150.0 produces a deserialization error.

Solution

1
use serde::{Deserialize, Deserializer};
2

3
#[derive(Debug, Clone, Copy)]
4
struct Percentage(f64);
5

6
impl Percentage {
7
    fn parse(value: f64) -> Result<Self, String> {
8
        if (0.0..=100.0).contains(&value) {
9
            Ok(Percentage(value))
10
        } else {
11
            Err(format!("percentage must be 0..=100, got {value}"))
12
        }
13
    }
14
    fn get(self) -> f64 {
15
        self.0
16
    }
17
}
18

19
impl<'de> Deserialize<'de> for Percentage {
20
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
21
    where
22
        D: Deserializer<'de>,
23
    {
24
        let value = f64::deserialize(deserializer)?;
25
        Percentage::parse(value).map_err(serde::de::Error::custom)
26
    }
27
}
28

29
#[derive(Debug, Deserialize)]
30
struct Discount {
31
    label: String,
32
    amount: Percentage,
33
}
34

35
fn main() {
36
    let good = r#"{ "label": "summer", "amount": 42.5 }"#;
37
    let bad = r#"{ "label": "broken", "amount": 150.0 }"#;
38

39
    match serde_json::from_str::<Discount>(good) {
40
        Ok(d) => println!("ok: {} -> {}%", d.label, d.amount.get()),
41
        Err(e) => println!("error: {e}"),
42
    }
43
    match serde_json::from_str::<Discount>(bad) {
44
        Ok(d) => println!("ok: {} -> {}%", d.label, d.amount.get()),
45
        Err(e) => println!("error: {e}"),
46
    }
47
}

Output:

1
ok: summer -> 42.5%
2
error: percentage must be 0..=100, got 150 at line 1 column 38

Input Validation and Sanitization

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

”Parse, don’t validate”

Type-driven validation with newtypes

Declarative validation with the validator crate

Key Differences

Common Pitfalls

Pitfall 1: Believing a TypeScript type validates anything at runtime

Pitfall 2: Making the newtype field public (or forgetting module privacy)

Pitfall 3: Validating but not normalizing

Pitfall 4: Trusting client-side validation

Pitfall 5: Using overly clever regexes for structured formats

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: A self-normalizing Slug newtype

Exercise 2: A validator-based DTO with a custom rule

Exercise 3: Deserialize directly into a validated newtype

Declarative validation with the `validator` crate

Exercise 1: A self-normalizing `Slug` newtype

Exercise 2: A `validator`-based DTO with a custom rule