Exercise 3: Confirming No CSRF Protection Exists — Possible Solution
====================================================================

SETUP
------------------------------
1. With the Astro dev server running on its usual local port (e.g.
   http://localhost:4321), open a second, completely unrelated local
   HTML file directly in the browser (a different origin entirely,
   e.g. a file:// page or a page served from a different port).

2. From that unrelated page's own browser console, issue:

     fetch('http://localhost:4321/api/pages/3/title', {
       method: 'POST',
       headers: { 'Content-Type': 'application/json' },
       body: JSON.stringify({ title: 'Changed From Another Origin' }),
     });

OBSERVED RESULT
------------------------------
The request succeeds - page 3's own title changes to "Changed From
Another Origin" - even though the request genuinely originated from
a different page/origin entirely, with no session, cookie, or token
proving it came from the real admin interface.

WHY THIS CONFIRMS THE GAP
------------------------------
Per this chapter, Rails' protect_from_forgery, Laravel's
VerifyCsrfToken, and Django's own CSRF middleware would all reject a
cross-origin request like this one by default. Astro's endpoint has
no equivalent check at all, so the request simply succeeds -
concrete, observable proof of the real, unaddressed limitation the
chapter names honestly rather than solving.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly demonstrates a genuine cross-origin POST succeeding
against the endpoint with no CSRF defense blocking it, confirming the
chapter's own claim that Astro provides no built-in protection here.