As shown in https://topanswers.xyz/meta?q=389#question full error stacks seem to be passed to the front end if anything fails.
Are we at risk of any of the following from this?
1. Helping potential attacks gain further vectors
2. Confusing the user
3. Lack of "What am I meant to do?" from the perspective of the user?
My take on this is that we should try and pass "friendly" error messages where possible to mitigate the above effects.
This (mostly) isn't an issue right now, because…
> 1. Helping potential attacks gain further vectors
Probably not — the only information that can leak would be information that the logged in user would be able to see anyway (for example their own login key). Still not ideal but nowhere near as bad.
One reason for this is that the front-end code has restricted access to the database — it can't see the actual tables underneath, only views and functions that are 'aware' of who the logged in user is. For example see this table and view:
create table chat_notification(
chat_id bigint references chat
, account_id integer references account
, chat_notification_at timestamptz not null default current_timestamp
, primary key (chat_id,account_id)
create view chat_notification with (security_barrier) as
> 2. Confusing the user
Yes — and perhaps we should dump a generic message instead if the user isn't registered.
> 3. Lack of "What am I meant to do?" from the perspective of the user?
It's very useful having that error message in full with bug reports (like the one you linked to). Even if the user doesn't know what the error means, as long as they pass it back to us in full, we have a much better chance of diagnosing and fixing the problem than if we just returned a 500 'something went wrong' message.
Of course further down the line we'll have to do that but for now I think the balance between risk and reward is towards keeping the full error message dumps.