CSRF Protection for Cookie-Authenticated Forms

Add CSRF protection to state-changing requests that rely on a cookie. GET stays safe. POST, PUT, and DELETE require a token or a header a cross-site form cannot set. APP Framework: [FRAMEWORK] Auth cookie SameSite: [LAX | NONE | STRICT] Clients: [OUR WEB APP ONLY | ALSO A PUBLIC API WITH TOKENS] DELIVER 1) The rule: cookie session plus a custom header (or a synchronizer token) on every mutation. A cross-site form post cannot set that header, so the browser's CORS preflight or the missing header blocks it. 2) Where the token is issued, how the client sends it, and how the server compares it in constant time if it is a secret token. 3) Exemptions: webhooks signed another way, the public token API if it does not use the cookie. List them so they do not grow by accident. 4) Tests: a same-origin POST with the header succeeds; a POST with the cookie and no header fails; a GET does not change data. 5) Why SameSite=Lax is not the whole story (subdomains, old browsers, GET requests that change state — and we will not have those). Do not disable CSRF because the API "is JSON." A form can still be posted where the content type allows it, and you will mention that.