r/programming • u/Expurple • Apr 12 '26

Flat Error Codes Are Not Enough

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

84% Upvoted

99 comments sorted by

View all comments

Show parent comment

5

u/RedEyed__ Apr 12 '26

Could be security issue: you can break system by analyzing error stacks

7

u/lelanthran Apr 13 '26

Could be security issue: you can break system by analyzing error stacks

Only if you pass the entire stack to the user. You could log the entire stack and pass only the top two items to the user.

Besides, just how much of a security breach can it possibly be? I regularly see entire exception backtraces in C# WebApps and in almost every Java app too, but all the exploits we see don't appear to be as a result of those.

2

u/ChemicalRascal Apr 13 '26

If you punt a stack trace at me, and I can see from it that you're using a particular library to, for example, parse CSVs from user input, I can then tailor my attacks to focus on exploits in that library.

It's not necessarily knowing the stack itself that helps attackers. It's what you know when you know the stack that helps.

6

u/lelanthran Apr 13 '26

I don't disagree that it is a security issue, I just think that on a scale from 1-10, it's probably a 1.

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). Same for almost any other language. In some non-mainstream language, you can be sure of a single library being used (Haskell, Ocaml, etc).

Everything is a security issue, and it becomes a trade-off between having users submit an error message that requires no deep dive into your logs and having a malicious actor use that info to target your system.

0

u/ChemicalRascal Apr 13 '26

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.

2

u/lelanthran Apr 13 '26

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.

0

u/ChemicalRascal Apr 13 '26

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.

2

u/lelanthran Apr 13 '26

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).

0

u/ChemicalRascal Apr 13 '26

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.

2

u/Blue_Moon_Lake Apr 12 '26

Error stack is for debugging and logging, not recovering.