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

SETUP
------------------------------
1. With the Express dev server running on its usual local port (e.g.
   http://localhost:3000), open a second, completely unrelated local
   HTML file directly in the browser (a genuinely different origin).

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

     fetch('http://localhost:3000/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 it genuinely originated from a
different page/origin, with no session, cookie, or token proving it
came from the real admin interface.

WHY THIS CONFIRMS THE GAP
------------------------------
Per this chapter, Express has no equivalent of Rails' own
protect_from_forgery, Laravel's VerifyCsrfToken, or Django's own CSRF
middleware. The request simply succeeds, concrete proof of the same
real, unaddressed limitation already named in the Astro rebuild's own
Chapter 8.

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
this chapter's own claim that Express provides no built-in protection
here either.