Default onError handler exposes internals on production

The default onError handler just outputs the error stack on production too, which IMO is a security concern, I think it would be much better if when process.env.NODE_ENV === 'production' it just returned a generic 500 error.

https://github.com/tinyhttp/tinyhttp/blob/08cff9e507ad8f4496a1181ea5e2b9d4baf50993/packages/app/src/onError.ts#L8-L16

[fabiospampinato]

to prove my point, Koa and Polka do absolutely the same with errors and no one shames them for that.

I’m not interested in convincing you of this, but if somebody is making a mistake pointing at other famous people that make the same mistake changes nothing, it’s still a mistake.

Well, you initially used express but that security issue didn’t concern you at the time? I don’t understand the logic behind that.

As I said I think having untrustworthy dependencies is a problem -> I moved from express to tinyhttp mainly because with that I’m relying on way less code (and from fewer people it seems) -> now that I’m learning about this problem I’m especially concerned about security with this too and I’m going to look into reducing the code I depend on further.

At the end of the day though I can’t rewrite the world, I have to trust someone at some point, vetting all the code I depend on it’s just not possible. Also the thing I was using express for previously, and tinyhttp currently, isn’t particularly security critical yet, there’s nothing of importance that could be stolen from there for example, this dependency pruning thing I’m going through is partially in preparation for when I’ll have the server handle authentication and other more juicy things.

Still I make no claim of doing everything perfectly security-wise myself, there are plenty of dumb thinks I do that I need to fix, for example npm install-ing arbitrary code from the internet in a non-sandboxed manner is a fairly risky thing that I still do unfortunately. It takes time to fix all these issues unfortunately.

idk what to say, everyone did that since the beginning of times

I mean you can wrap a few things, if everyone did that all the time unhandled exceptions would be a thing at all. Some frameworks from what I’ve seen even encourage not handling errors in route handlers because those are handled automatically by the framework itself. I don’t think being extremely defensive about that is what most people do at all, but maybe my perception is skewed.

you can supply your own onError handler to tinyhttp contructor in case you dislike the standard approach

That’s what I’m doing at the moment, thanks for the suggestion.

To be clear I don’t think this is a monumental issue, I think it’s unlikely that any of the important dependencies I’m currently using is stupid enough to leak secrets like that, and even exposing some information about the code that runs on my server shouldn’t be a problem, I’m much more happy about tinyhttp where a lot of the dependencies you wrote yourself than I am with express which imports the world along with it, still the less the better, maybe I can fork Polka and go with that or something.

[talentlessguy]

good that it got settled down

thank you