do you have any misunderstandings about CSRF and JWT?

JWT is just an authentication credential, which is not contradictory to the fact that you use it to guard against CSRF. You can add measures to prevent CSRF on top of JWT, such as checking the Referer field and adding a check token (that is, CSRF Token)).

check the Referer field

HTTP header that indicates which address the request came from. When processing sensitive data requests, generally speaking, the Referer field should be under the same domain name as the requested address. In the bank operation above, for example, the address of the Referer field should usually be the web address where the transfer button is located, which should also be under www.examplebank.com. If it is a request from a CSRF attack, the Referer field will be the address that contains the malicious URL and will not be under the www.examplebank.com, so the server will be able to identify the malicious access.

this method is simple and easy, the workload is low, and only one step of verification is needed at the key access points. But this approach also has its limitations, because it relies entirely on the browser to send the correct Referer field. Although the content of this field is clearly defined in the http protocol, it cannot guarantee the specific implementation of the visiting browser, nor can it guarantee that there are no security vulnerabilities in the browser that affect this field. It is also possible for an attacker to attack some browsers and tamper with their Referer fields.

add check token

because the essence of CSRF is that the attacker deceives the user into accessing the address set by himself, if the user's browser is required to provide data that is not saved in the cookie when accessing sensitive data requests, and the attacker cannot forge data as a check, then the attacker can no longer perform a CSRF attack. This kind of data is usually a data item in a form. The server generates it and appends it to the form, and its content is a pseudo-random number. When the client submits a request through the form, the pseudo-random number is also submitted for verification. During normal access, the client browser can correctly get and return this pseudo-random number, but in the fraudulent attack sent through CSRF, the attacker does not know the value of the pseudo-random number in advance, and the server will reject the suspicious request because the value of the check token is empty or incorrect.

Hello, according to my personal understanding, the main premise of a CSRF attack is that the attacker cannot obtain the user's cookie , but the malicious link induces the user to submit a request to the relevant interface through the attacker's link. The value of cookie is carried by default, while the value of jwt needs to be extracted through the js code of the front-end page and submitted to the backend for verification. The attacker can not get the user's jwt, and can not take it out through js, so jwt can prevent CSRF attacks.
simply put, a CSRF attack means that the request did not come from the correct front-end page, while jwt requires the front-end to take it out actively .