or
GeorgePalacios
bug wont-fix
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.
Top Answer
Jack Douglas
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:

```sql
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)
);
```

```sql
create view chat_notification with (security_barrier) as
select chat_id,chat_notification_at
from db.chat_notification
where account_id=current_setting('custom.account_id',true)::integer;
```

> 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.
Error details on the front end
GeorgePalacios replying to Jack Douglas
That sounds perfect to me
Josh Darnell replying to Jack Douglas
I like that idea!
Josh Darnell replying to Jack Douglas
That's a good point about open source, it definitely means that some of those things would be know factors for anyone looking.
Jack Douglas
what do you think of the idea of presenting a generic 'something went wrong' message with a code that we can use to reference the error dump?
Jack Douglas
Thanks very much for the input @Josh, it's much appreciated, because there are lots of holes in my knowledge on subjects like this. My thinking was the we aren't exposing much more than we will be exposing to everyone when we open-source, but that might not be the case.
Josh Darnell
It also just occurred to me that I don't know anything about your background other than from seeing you on dba.se and here, so sorry if this comes across as talking down - I certainly don't mean it that way!
Josh Darnell
I realize this isn't the chief concern right now, and is being weighed appropriately ("*balance between risk and reward*").  But I also wanted to make sure it doesn't get totally swept under the rug :)
Josh Darnell
I'm not a security expert by any stretch, but thought I'd point out / support that this is [a legitimate penetration testing / attack vector](https://www.owasp.org/index.php/Improper_Error_Handling).
Josh Darnell
@Jack "*the only information that can leak would be information that the logged in user would be able to see anyway*" I just wanted to point out that a lot of information that's useful to an attacker gets leaked or implied by these messages (what the database backend is, what the web server / OS is, possibly info about specific versions, detailed database schema / naming conventions, etc).
Jack Douglas
I didn't mean casual users — they are trading the most tested paths anyway. I meant 'power' users who are finding errors in some niche area
GeorgePalacios
It becomes in effect, another barrier to participation
GeorgePalacios
For me, if I use a site and it errors, 90% of the time I'll just log off and never use it again
GeorgePalacios
I would honestly be shocked if that did happen.
Jack Douglas replying to GeorgePalacios
yes I agree we should log everything, but I don't think we'll examine every log — the presumption is that users will report the most important issues
GeorgePalacios
Also, I'd argue we want every error that affected the use of the site reporting
GeorgePalacios
Debugging is hard after the fact, you know?
GeorgePalacios
As a counter-point to that - wouldn't it be better to log everything and figure out a way to filter down the noise?
Jack Douglas replying to GeorgePalacios
I'm not sure we want every error reported
GeorgePalacios
Could we not pop up a nice and easy "There's been an error - click here to report it" along with the error itself?
Jack Douglas
we could probably dump a reference to the user with a message saying 'please quote this reference in your bug report
Jack Douglas replying to GeorgePalacios
yes that's still harder work though because we have to correlate the actual error dump with a bug report that might be posted later.
GeorgePalacios
@Jack In that case I would suggest working on internal error dumps rather than relying on the user - appreciate it's not top priority at this stage.
Caleb
See also [this request](https://topanswers.xyz/meta?q=347#question) which hits on this issue too (although the primary request was fixing a specific error).