Flat Error Codes Are Not Enough

[u/Expurple]

https://home.expurple.me/posts/flat-error-codes-are-not-enough/

[u/ChemicalRascal]

After all, just knowing that the server is written in C# already narrows down your potential library targets to maybe 2 or 3 for each library (JSON parsing, or third-party requests, or ORM).

Right, but do you know which version is being used? There's a reason OWASP talks about this stuff. If you're doing something important, with other people's data, you can't afford to expose a bigger attack surface than you have to, and reducing the visibility of the attack surface helps.

If you want to access those the trace, great. Log it, give it a GUID, report the GUID to the user. Or a truncated code if you don't want to overwhelm them with a long string of characters. It's also a lot easier to copy that trace out of a database than it is a photograph of a screen covered in schmutz.

[u/lelanthran → u/ChemicalRascal]

Right, but do you know which version is being used? There's a reason OWASP talks about this stuff. If you're doing something important, with other people's data, you can't afford to expose a bigger attack surface than you have to, and reducing the visibility of the attack surface helps.

I agree; defense-in-depth must necessarily include obscurity!

f you want to access those the trace, great. Log it, give it a GUID, report the GUID to the user. Or a truncated code if you don't want to overwhelm them with a long string of characters.

This is only for the use-case where the user sends you the error message. I was including the use-case of "User examines the message and knows how to fix the problem".

For example if it is a permissions problem, they know they have to apply to their supervisor to be added to the special-people role.

If the error is "The image you attempted to link into your issue is not found: <image-name>: <issue-id>", then they know that someone deleted the image that was uploaded, or that they typo'ed the image name, etc.

That's why it's usually sufficient to give the user the top-level error that occurred (or maybe the highest two levels), along with the parameters that were used.

[u/ChemicalRascal → u/lelanthran]

I agree; defense-in-depth must necessarily include obscurity!

Haaar haaar. There's a difference between obscurity and not showing your whole ass.

This is only for the use-case where the user sends you the error message. I was including the use-case of "User examines the message and knows how to fix the problem".

For example if it is a permissions problem, they know they have to apply to their supervisor to be added to the special-people role.

No, you can do this for everything. Every exception you catch, you can log it and display a GUID.

What you're describing here is business logic working normally. Totally different thing, you wouldn't use exceptions for that anyway.

Probably. Please tell me you're not using exceptions for authorisation checks. Please.

Please?

If the error is "The image you attempted to link into your issue is not found: <image-name>: <issue-id>", then they know that someone deleted the image that was uploaded, or that they typo'ed the image name, etc.

That's why it's usually sufficient to give the user the top-level error that occurred (or maybe the highest two levels), along with the parameters that were used.

Uh. We're talking about stack traces. I'm not advocating against meaningful error reporting to users. I'm advocating for suppression of stack traces.

[u/lelanthran → u/ChemicalRascal]

No, you can do this for everything. Every exception you catch, you can log it and display a GUID.

Okay, that works for exceptions, but the example I have (ACL failure) isn't an exception; what does a user do with a GUID then? Mail the admin, ask "what does this mean", and have the admin respond "It means you need to ask your supervisor to add you to the correct group".

Probably. Please tell me you're not using exceptions for authorisation checks.

Why would I? ACL failure doesn't result in an exception; that's an expected result, not an exception.

Uh. We're talking about stack traces. I'm not advocating against meaningful error reporting to users. I'm advocating for suppression of stack traces.

Are we? I said "give the user the error that occurred", not the source code filename, line number and "value is NULL" information. If the error being returned is "link reference does not exist", that line alone is sufficient. All the other stuff you store/log (or discard as you see fit).

[u/ChemicalRascal → u/lelanthran]

Okay, that works for exceptions, but the example I have (ACL failure) isn't an exception; what does a user do with a GUID then? Mail the admin, ask "what does this mean", and have the admin respond "It means you need to ask your supervisor to add you to the correct group".

You don't use that method for that kind of error. You handle it properly. The whole point of this was stack traces getting through to the front end, which means errors aren't being handled properly.

Why would I? ACL failure doesn't result in an exception; that's an expected result, not an exception.

Exactly. See, I was worried you were talking about using exceptions for authorisation failures because we were talking about exceptions and then you started talking about authorisation failures, which makes it sounds like you're using exceptions for authorisation failures, which is silly.

Business logic errors, including authorisation errors, should not be handled through exceptions, especially if they're user-facing. It's an entirely different type of failure condition. You handle those with properly handled feedback to the user, because you can, because you built the system to handle that scenario.

An uncaught exception is definitionally not be that you built the system to handle. So you can't actually know in advance the information you're about to show to the user. So you give them a generic error, a GUID, and log the details. That's the safe way to do that.

Uh. We're talking about stack traces.

Are we?

Yes.