The form is careful.
The email field checks the shape.
The quantity will not go below one.
The discount field is read only.
The date picker will not offer you
a day in the past.
All of it works.
All of it runs on a machine
you do not own.
Every one of those rules
is a suggestion made to a browser,
and the person holding that browser
can open the console
and change any value
in about four seconds.
They do not even need the browser.
Your endpoint accepts a request.
curl sends a request.
The form was never involved.
This is not mainly a story about attackers.
Most of the traffic that skips your form
is entirely ordinary.
The mobile app, written by another team,
that calls the same endpoint
and has never seen your date picker.
The partner integration.
The internal script that imports
five thousand rows at a time,
because doing it through the interface
would take a fortnight.
Your own retry path.
Every one of those is a caller
that has never run a line
of your JavaScript.
So a quantity of minus four
lands in the database.
A discount of ninety nine percent
arrives on a real order,
because the field was read only
in exactly one of the five places
where orders get made.
No one attacked anything.
The rule was simply written
in the one layer
that cannot enforce it.
The fix is not to strip the checks
out of the form.
Keep them.
They are good manners
and they save people a round trip.
The fix is to write the rule
where the data actually arrives,
and to treat the browser copy
as a convenience that may be wrong,
missing, or three versions old.
There is an exercise for this
and it takes a morning.
Take your most important endpoint.
Send it every value
your form refuses.
Empty, negative, enormous,
the wrong type,
the past, the far future.
See what it stores.
Whatever it accepts
is what your product actually allows.
The form describes your intentions.
The endpoint describes your rules.
– Serguey Asael Shinder
Top comments (1)
is this a poem?