This page builds directly on the previous idea that security begins with predictable shape.
Security begins at the boundary.
Before escaping, before hashing, before permissions, before anything else
— the system must decide what it will accept and what it will reject.

Modern PHP makes this easier,
but only if we treat input shape as a first‑class concept.

A secure system does not accept “almost valid” data.
It accepts only what it understands.

This page introduces the mindset of shaping, validating,
and rejecting input with clarity.

Validation is not a series of checks.
It is the act of shaping untrusted data
into a predictable form.

A secure system:

• defines the shape it expects
• rejects anything outside that shape
• never guesses
• never coerces
• never fills in missing meaning

If the input doesn’t match the shape,
the system says no.

One of the most overlooked security principles is
Unknown fields are not harmless
— they are untrusted.

A secure boundary

• accepts only known fields,
• rejects everything else,
• never silently ignores extra data.

Silent acceptance is how vulnerabilities slip in.

Validation belongs at the edge of the system:

• HTTP request → validate
• CLI input → validate
• API payload → validate
• file upload → validate

Once data crosses the boundary,
it should already be

• typed
• shaped
• predictable
• safe

Internal code should never wonder whether
the input is valid.

Arrays are flexible.
Flexibility is the opposite of security.

DTOs give you:

• stable shape
• typed properties
• predictable structure
• no dynamic keys
• no silent coercion

A DTO is a contract.
An array is a suggestion.

PHP will happily coerce

• strings to numbers,
• numbers to strings,
• empty strings to false,
• null to empty arrays,
• arrays to booleans.

This is convenient
— and dangerous.

Safe defaults:

• cast explicitly
• convert intentionally
• reject ambiguous values
• avoid “truthy” logic
• avoid loose comparisons

Predictability
is security.

A value can be “valid”
but still unsafe.

Examples:

"123" is not an integer

"true" is not a boolean

"[]" is not an array

"null" is not null

"5" is not a float

Safe validation → checks for

• type
• shape
• structure
• domain
• intent

Security is not about correctness
— it's about clarity.

Before checking meaning,
check shape.

Example for a user registration payload:

1. Is it an object?
2. Does it contain exactly the expected fields?
3. Are the fields the correct types?

Only then: check length, format, domain rules.

Structure first.
Meaning second.

A secure system:

• rejects early
• rejects clearly
• rejects loudly

So, do not:

• sanitize silently
• guess intent
• auto‑correct
• fill in missing fields
• “fix” malformed data

A system that fails loudly
is harder to exploit.

User‑friendly error messages belong in the UI.
Strict validation belongs in the backend.

Security validation should be

• strict
• unforgiving
• predictable
• consistent

Friendly messages can wrap strict rules
— not replace them.

Input validation
is the first and most important security boundary.

A secure system

• shapes data,
• rejects unknown fields,
• validates at the boundary,
• uses DTOs for stable structure,
• avoids implicit coercion,
• validates types and shape,
• checks structure before meaning,
• fails fast and loudly

Security begins with predictable input.
Everything else builds on that foundation.

This page describes secure defaults and common practices in modern PHP. It is not a complete security guide, and it does not replace formal audits or framework‑specific documentation. These principles are consistent enough to be useful, but security always requires context, judgment, and ongoing review.

• Top↑
• Back to Topic ↔
• Home←