The account page shows six things.
Name, plan, renewal date,
two counters and a status.
The response that fills that page
has forty one fields in it.
Internal notes.
The flag that says this one
is under review.
A risk score somebody
generates on a Monday.
The identifier of the salesperson
who owns them.
An email address
belonging to a different person
at the same company.
All of it arrived
in the customer's browser
and was thrown away
by the part of your program
that decides what to draw.
Nobody attacked anything.
The data was sent to them.
Here is how it happens,
and nobody ever chose it.
Hiding a column is a rendering decision.
Sending a column is a disclosure decision.
They get made in the same file,
in the same afternoon,
by the same person,
and only one of them
feels like it has consequences.
So the handler loads the row,
the whole row, because that is
what the query returns,
and the template is trusted
to be discreet.
Then it spreads.
The app calls the same endpoint.
The customer's own page calls it
with a different role
and gets the same shape,
because the shape was decided
by the table, not by the audience.
It also reaches places
you do not run.
A browser keeps it in history.
A proxy at the customer's employer
holds a copy of everything
their staff loaded that week.
A screenshot of your admin page
goes into a support thread
with the whole payload
sitting underneath it.
And the day you find out,
you cannot scope it,
because nothing in your logs
records what you sent,
only that you answered two hundred,
so the damage has no boundary
and no date.
Treat the response as the interface.
Build the object you mean to send,
field by field, on the server,
for this caller, in this role.
Not the row with the awkward parts
painted over at the far end.
Then go and look.
Open your own product,
open the network tab,
read what your service
just handed to a stranger.
It takes four seconds,
which is exactly as long
as it takes anybody else.
– Serguey Asael Shinder
Top comments (0)