I watched a training video on authorization and authentication by token, and there is an entry http.csrf().disable() in the method that connects the filters. Why do we disable csrf protection, the person did not explain? Here's the full class for a better idea of what I'm talking about:
@Configuration
@RequiredArgsConstructor
public class SecurityConfig{
private final JwtTokenProvider jwtTokenProvider;
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.httpBasic().disable()
.csrf().disable()
.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
.and()
.authorizeHttpRequests(authz ->
{
try {
authz
.requestMatchers("/api/auth/**").permitAll()
.requestMatchers("/api/admin/sensors/**").hasAuthority("ROLE_ADMIN")
.requestMatchers("/api/sensors/**").hasAnyAuthority("ROLE_ADMIN", "ROLE_USER")
.anyRequest().authenticated()
.and()
.apply(new JwtConfigurer(jwtTokenProvider));
} catch (Exception e) {
throw new RuntimeException(e);
}
}
);
return http.build();
}
}
CSRF is a vulnerability where an attacker exploits the way browsers work. In more traditional web applications, your session token (which allows the app to authenticate requests) is sent in a cookie. Cookies are sent by browsers with requests based on where the request goes to, and regardless of the origin the request was made from. So if you are logged in to such an application, and visit a malicious site, that malicious site can have you make inadvertent requests to the victim site, and your session cookie will be sent automatically. So to prevent an attacker from setting up such a malicious site and have you make requests to the victim one potentially performing things you didn't want to, the victim site needs to implement protection against CSRF. There are multiple techniques to achieve this, for example the website can create a random CSRF token, include it in forms and store it server-side, expecting it back with every form submission. This works, because the attacker, when making a request from the malicious site will have no way to include the correct token. (Also the token belongs to an authenticated user, so even if the attacker does download a page to get a CSRF token, that will not be valid for another logged on user.)
Notice that all of the above relied on the fact that a cookie will be sent automatically. If, as in your example, the authentication token is sent as something lese (like as an Authorization header), that will not be automatically included by the browser. The attacker on a malicious website can still have you make a request to the victim site, however, you auth info cannot be included, so it will not work anyway - whatever such a request can do, the attacker could do by himself anyway (except some very special cases).
For this reason, CSRF protection can be disabled, if authencation is based on something that's not sent automatically.