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.