## Description The backend listens on all network interfaces, so port 3001 is reachable directly from the public internet, bypassing Apache's reverse proxy entirely. This defeats the point of proxying `/project2/graphql` through Apache (same-origin, no CORS, one place to add access control later). Confirmed with `nmap it2810-13.idi.ntnu.no`: ``` PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 3001/tcp open nessus <- actually the GraphQL API, nmap's service guess is wrong ``` and directly querying it from outside the VM: ```bash curl -X POST http://it2810-13.idi.ntnu.no:3001/ \ -H 'Content-Type: application/json' \ -d '{"query":"{ recipes(limit:1){totalCount} }"}' # -> {"data":{"recipes":{"totalCount":17698}}} ``` **Root cause**: `backend/src/index.ts` calls `startStandaloneServer(server, { listen: { port } })` without a `host`. Node's HTTP server defaults to binding all interfaces (`0.0.0.0`) when `host` isn't given. **Impact**: not a data leak by itself (the same data is already public through the proxied endpoint, no auth either way), but it bypasses the same-origin assumption any browser-side CORS behaviour relies on, and bypasses whatever access control might later be added at the Apache layer. Worth closing as a hygiene/defense-in-depth fix. ## Steps to reproduce 1. `nmap it2810-13.idi.ntnu.no` from any machine outside the VM. 2. Port 3001 shows open. 3. `curl -X POST http://it2810-13.idi.ntnu.no:3001/ -d '{"query":"{ recipes(limit:1){totalCount} }"}'` returns real data. ## Expected behavior Port 3001 only answers from `localhost` on the VM (i.e. from Apache). Querying `it2810-13.idi.ntnu.no:3001` from outside should get no response (connection refused/timeout), the same way it would if the backend weren't there at all. ## Fix `listen: { port, host: '127.0.0.1' }` in `backend/src/index.ts`. Verify locally that `curl http://127.0.0.1:3001` still works and `curl http://<your-LAN-IP>:3001` from another machine doesn't, then deploy to the VM and restart `t13-backend` (`sudo systemctl restart t13-backend`), and re-run `nmap` against the VM to confirm 3001 no longer shows open.