harden: add CSRF protection in server.js...

[anupamme]

Summary

Harden input handling in appengine/building-an-app/update/server.js (flagged by semgrep).

Vulnerability

Field	Value
ID	javascript.express.security.audit.express-check-csurf-middleware-usage.express-check-csurf-middleware-usage
Severity	HIGH
Scanner	semgrep
Rule	javascript.express.security.audit.express-check-csurf-middleware-usage.express-check-csurf-middleware-usage
File	appengine/building-an-app/update/server.js:21
Assessment	Defensive hardening

Description: A CSRF middleware was not detected in your express application. Ensure you are either using one such as csurf or csrf (see rule references) and/or you are properly doing CSRF validation in your routes with a token or cookies.

Threat Model Context

This is a private Node.js application (not published to npm). Vulnerabilities affect this application's own runtime only.

Changes

• appengine/building-an-app/update/server.js
• appengine/building-an-app/update/package.json

Behavior Preservation

The change is scoped to 2 files on the vulnerable path; it only tightens handling of untrusted input and leaves valid inputs unaffected.

Security Invariant

Property: The security boundary is maintained under adversarial input

Regression test

const request = require('supertest');
const app = require('./appengine/building-an-app/update/server.js');

describe('CSRF protection: state-changing requests without valid CSRF token should be rejected or protected', () => {
  const payloads = [
    { method: 'post', path: '/', body: { title: 'malicious post', author: 'attacker' }, origin: 'http://evil.com' },
    { method: 'post', path: '/', body: { title: '<script>alert(1)</script>', author: 'xss' }, origin: 'http://attacker.example.org' },
    { method: 'post', path: '/', body: {}, origin: 'http://cross-site-forgery.com' },
  ];

  payloads.forEach((payload, idx) => {
    it(`rejects or protects against cross-origin state-changing request #${idx + 1}`, async () => {
      const res = await request(app)
        [payload.method](payload.path)
        .set('Origin', payload.origin)
        .set('Content-Type', 'application/x-www-form-urlencoded')
        .send(payload.body);

      // A properly CSRF-protected app should either:
      // 1. Return 403 for missing/invalid CSRF token, OR
      // 2. Use SameSite cookies + verify origin, OR
      // 3. At minimum not return a successful 2xx for cross-origin POST without token
      const isProtected = res.status === 403 || res.status === 401 || res.status === 400 || res.status === 422;
      const hasCSRFHeader = res.headers['x-csrf-token'] || res.headers['set-cookie'];

      // If the request succeeds (2xx or 3xx redirect), the app lacks CSRF protection
      // This assertion documents the security requirement: cross-origin POSTs without
      // a CSRF token MUST NOT succeed with 2xx
      if (!isProtected) {
        // Flag that CSRF middleware is missing - the request should not succeed
        const succeeded = res.status >= 200 && res.status < 400;
        if (succeeded) {
          throw new Error(
            `CSRF vulnerability: cross-origin POST from "${payload.origin}" succeeded with status ${res.status}. ` +
            'State-changing requests must require a valid CSRF token.'
          );
        }
      }
    });
  });
});

This test guards against regressions — it's useful independent of the code change above.

---

This patch removes an exploit primitive — a code pattern that, while not independently exploitable today, could be chained with other weaknesses by automated exploit-development tooling. Proactive removal of such primitives raises the bar against increasingly capable automated attack tools.

---

Automated security fix by OrbisAI Security

[gemini-code-assist]

Code Review

This pull request introduces CSRF protection to the App Engine application by adding cookie-parser and csurf dependencies and configuring them in server.js. However, the implementation hardcodes the HTML form directly in the /submit route, bypassing the existing views/form.html template. The feedback recommends reading the template file dynamically using the promise-based fs.promises API and injecting the CSRF token, which keeps the code clean and maintains the project's tutorial structure.

[gemini-code-assist]

Hardcoding the HTML form directly in server.js bypasses the existing views/form.html file, leaving it as dead code and breaking the tutorial structure. Instead, read the HTML file dynamically and inject the CSRF token into the form. Since this is an asynchronous file system operation, use the promise-based fs.promises API with async/await as per the project's guidelines.

app.get('/submit', async (req, res, next) => {
  try {
    const token = req.csrfToken();
    const template = await fs.readFile(path.join(__dirname, '/views/form.html'), 'utf-8');
    const html = template.replace(
      '<form method="POST" action="/submit">',
      `<form method="POST" action="/submit"><input type="hidden" name="_csrf" value="${token}">`
    );
    res.send(html);
  } catch (err) {
    next(err);
  }
});

References

1. For asynchronous file system operations in Node.js, use the promise-based fs.promises API when working with async/await.

[gemini-code-assist]

To avoid hardcoding the HTML form in server.js and keep using the existing views/form.html template, we need to import the fs and path modules. This allows us to read the HTML file asynchronously and inject the CSRF token dynamically.

Suggested change

	const cookieParser = require('cookie-parser');
	const csrf = require('csurf');
	const cookieParser = require('cookie-parser');
	const csrf = require('csurf');
	const fs = require('fs').promises;
	const path = require('path');

References

1. For asynchronous file system operations in Node.js, use the promise-based fs.promises API when working with async/await.

[anupamme]

✅ Review Feedback Addressed

I've automatically addressed 2 review comment(s):

The reviewers flagged two issues:

1. (Medium) The fs and path modules are missing from the imports. They're needed to read views/form.html asynchronously.
2. (High) The /submit GET route hardcodes the entire HTML form inline, bypassing the existing views/form.html template. The fix reads the template file with the promise-based fs.promises API (async/await), injects the CSRF hidden input into the existing <form> tag, and passes any errors to Express's next error handler — exactly as the reviewer suggested.

Files modified:

• appengine/building-an-app/update/server.js

The changes have been pushed to this PR branch. Please review!