Who can access the X-CSRF token?

Question

I'm really confused about a CSRF token implementation in a Spring web app that I've inherited. Basically, everyone can request the token by looking at what Spring Security filters do:

        http
        .exceptionHandling()
        .authenticationEntryPoint(new RestAuthenticationEntryPoint())
        .and()

        .authorizeRequests()

        .antMatchers(HttpMethod.GET,"/token").permitAll()

Initially I tought that the protection comes from the SOP, but the creator of the implementation told me that is not SOP that grant protection without specifying further. So, in a few words, is it correct to prevent CSRF in this way? Because I feel that something is missing, but I can't realize what.

Answer 1

This is a quite normal way of protection against CSRF.

What is CSRF? It is when an attacker tricks your user to click a link/button and trigger a function in your application that user otherwise would not like to trigger. For instance, an attacker tricks a user to place an order in your application with the attackers delivery address.

It is considered a good practice that any operations that change any data are only triggered via POST, PUT, PATCH, DELETE and that GET does not change anything. Then what will happen if an attacker tricks a user to trigger some GET operation? User will receive the data from your application that he can anyway see. There is nothing harmful in this. That's why there is usually no sense in protecting GET requests against CSRF.

Update:

After comments from the author below it seems that it is a single page application, because if HTML was rendered on server, server could inject the token and it would be not needed to request the token separately.

The case with SPA is addressed already, for instance, see here:

• https://blog.eq8.eu/article/rails-api-authentication-with-spa-csrf-tokens.html
• https://stackoverflow.com/questions/50159847/single-page-application-and-csrf-token

It is not wrong to get token in such way. But permitAll() should no be used, otherwise an attacker can create a request with a correct token.