Re: Row data is reflected in DETAIL message when constraints fail on insert/update

Shay Rojansky <roji(at)roji(dot)org> writes:

>> I don't think that's true - schema information (table, column names)
>> definitely seems like it's in a different category than table contents.
>
> You're not visualizing this with the appropriate amount of paranoia: just
> because the database thinks that something is a table or column name
> doesn't mean that that's what it actually is. A screw-up in query syntax
> could lead to reporting back something that was really a data value.
> Admittedly, that's not very likely given a well-debugged application
> issuing the queries, but it's not something to ignore either.

Good point, thanks. I guess the main thing I'm trying to say is that in the
standard, "default" scenario we should consider doing our best to avoid
data leaks, rather than approaching this as a 100% all-or-nothing problem..

>> First, there are many lazily-written applications out there which simply
>> show exception/error messages to users. So user A could interact with a
>> website in a way that triggers a unique constraint violation, and thereby
>> get access to the data in the row which caused the violation.
>
> Well, that's just bad webapp design ...

True, but as this is a potentially critical security/privacy concern it
seems reasonable to do what we can to prevent these leaks, even if
ultimately they are the app developer's fault/responsibility.

Basically at the moment there's a "pit of failure" where an inexperienced
dev doing a standard application has a high chance of encountering this
issue, and unfortunately most of the Internet is made up of this scenario.
I'm only proposing to protect against the obvious/easy data leak scenarios
via an opt-in.