How can the frontend help the backend defend against CSRF? Explain CSRF tokens, the double-submit cookie, custom headers and Fetch Metadata.

The frontend's job is to send proof that the request came from your own page. An attacker's site can make the browser send your cookies, but it can't read your pages or add custom headers.

The common methods:

• CSRF token: the server puts a random token in the page or in an API response. The frontend sends it back in a header such as X-CSRF-Token on every request that changes data. The attacker can't read the token, so it can't send it.
• Double-submit cookie: the server sets a random value in a cookie that is not HttpOnly. JavaScript copies it into a header, and the server checks that the two match. It is weaker if an attacker can set cookies from a subdomain. So sign the value and tie it to the session, and use the __Host- cookie prefix.
• Custom header: a cross-origin request with a custom header like X-Requested-With needs a CORS preflight. A strict CORS setup rejects it, and plain forms can't add headers at all. This only works if your CORS setup is strict.
• Fetch Metadata: browsers add Sec-Fetch-Site automatically, with values like same-origin or cross-site. The server can reject cross-site requests that change data. The frontend does nothing here.

Also keep GET requests read-only, and keep SameSite cookies as the base layer.