Describe the bug When trace logging is active a simple GET request that does not require CSRF protection logs the following:

Did not protect against CSRF since request did not match CsrfNotRequired [TRACE, HEAD, GET, OPTIONS]

But it is indeed a GET request.

To Reproduce Enable spring security, use trace level logging, perform GET request.

Expected behavior Log message should state the correct condition.

Sample Problem is in https://github.com/spring-projects/spring-security/blob/e1d8033ee39d04bde0f58d70bce3a262ecbd1d9d/web/src/main/java/org/springframework/security/web/csrf/CsrfFilter.java#L114

The logic

if (!this.requireCsrfProtectionMatcher.matches(request)) {
            if (this.logger.isTraceEnabled()) {
                this.logger.trace("Did not protect against CSRF since request did not match "
                        + this.requireCsrfProtectionMatcher);
            }
            filterChain.doFilter(request, response);
            return;
        }

matches the intended log message, but the log message uses the toString method of DefaultRequiresCsrfMatcher which references allowed methods and the matcher again negates the condition, leading to a mismatch between output and behaviour.

        @Override
        public String toString() {
            return "CsrfNotRequired " + this.allowedMethods;
        }

Comment From: jzheaux

Hi, @everflux, thanks for reaching out. I agree that this message could be confusing and could use a change.

I believe the issue is that it correctly states that it won't protect, but it's reasoning is hard to parse. The following would be more correct:

Did not protect against CSRF since request did not match IsNotHttpMethod [TRACE, HEAD, GET, OPTIONS]

In this way, if someone configures a custom request matcher, the message can still make sense:

Did not protect against CSRF since request did not match HttpMethod [POST]

However, since there are a lot of negations in the default, we could use a simpler error message when the class is using the default DefaultRequestCsrfMatcher:

Did not protect against CSRF since IsNotHttpMethod [TRACE, HEAD, GET, OPTIONS]

Are you able to contribute a PR that simplifies the log message when the filter is using its default request matcher? It would also be nice to change the toString to use IsNotHttpMethod.