Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove unused message val #234

Merged
merged 1 commit into from
Jun 13, 2024
Merged

Remove unused message val #234

merged 1 commit into from
Jun 13, 2024

Conversation

rtyley
Copy link
Member

@rtyley rtyley commented Jun 13, 2024

This follows on from #233 - it turns out the message val is now unused, so we can remove it, and simplify the code a little!

PR #233 removed the exception message text from the error displayed to the end user, because the error message text is unconstrained and this corresponds to https://owasp.org/www-community/Improper_Error_Handling .

I was tempted to re-include the desc string in the error message displayed to the user, as it is just the string "anti-forgery-token-invalid" or the exception class name, which is more constrained, but re-reading the OWASP doc, this is also discouraged as it's very similar to an error code. ("internal error messages such as stack traces, database dumps, and error codes"). When getting error reports in the past, I've found it helpful if they have received an error with a bit more context in it, as surprisingly the error reports often don't include the user that saw the error, or when the error occurred, making it harder to search logs for them! Still, I do appreciate the guidance from OWASP is right.

This follows on from #233 -
it turns out the `message` val is now unused, so we can remove it, and simplify
the code a little!

PR #233 removed the exception message text from the error displayed to the end user,
because the error message text is unconstrained and this corresponds to
https://owasp.org/www-community/Improper_Error_Handling .

I was tempted to include the `desc` string in the error message displayed to the user,
as it is just the string "anti-forgery-token-invalid" or the exception class name, which
is more constrained, but re-reading the OWASP doc, this is also discouraged as it's
very similar to an error code. ("internal error messages such as stack traces, database
dumps, and error codes"). When getting error reports in the past, I've found it helpful if
they have received an error with a bit more context in it, as surprisingly the error reports
often don't include the user that saw the error, or when the error occurred, making it harder
to search logs for them! Still, I do appreciate the guidance from OWASP is right.
@rtyley rtyley requested a review from a team as a code owner June 13, 2024 09:37
Copy link
Member

@johnduffell johnduffell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point, didn't actually look at the code properly I just edited in GH 👍

@johnduffell
Copy link
Member

regard your comment Roberto, I think the important thing is that we specifically only allow the specific information that we are happy for the user to see, rather than just hiding everything.
So if we are pattern matching an exception with some specific field that gives information we are happy to share, then we can put that in (in my opinon).
I also think a link to the cloudwatch logs would be useful, focussed in on the specific line that has the issue, but I realise that's wishful thinking!

@rtyley rtyley merged commit c07f923 into main Jun 13, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants