Potential fix for code scanning alert no. 9: Workflow does not contain permissions

[ejscribner]

Potential fix for https://github.com/couchbase-examples/nextjs-quickstart/security/code-scanning/9

Add an explicit permissions block to the workflow with least privilege required for current behavior. The best single fix is to define it at the workflow root so it applies to all jobs (current and future unless overridden), using contents: read as the minimal baseline recommended by CodeQL.

In .github/workflows/cb-service-container.yml, insert:

permissions:
  contents: read

directly after the trigger section (on: block) and before jobs:.
No imports, methods, or dependencies are needed.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
couchbase-nextjs-quickstart	Ready	Preview	Sep 30, 2026 3:52pm UTC
nextjs-quickstart	Ready	Preview	Sep 30, 2026 3:52pm UTC

[ejscribner]

@dex-the-ai can you review this for me? Ensure that it covers all vulnurabilities described on https://github.com/couchbase-examples/nextjs-quickstart/security/code-scanning and if it doesn't, add fixes for each.

[dex-the-ai]

@ejscribner I reviewed the PR against the open code scanning alerts. It fixed 2 of the 5 open alerts. I pushed d1f87aa to fix the other 3.

Alert	Rule	Location	Status
#9	actions/missing-workflow-permissions (medium)	.github/workflows/cb-service-container.yml	✅ Fixed by 10993b0: permissions: contents: read at the workflow root. That's enough for this workflow: actions/checkout only needs read access, and the Slack step uses a webhook secret, not GITHUB_TOKEN.
#4	js/request-forgery (critical)	pages/index.js (load profiles)	✅ Fixed by bee0582: the URL is now relative (/api/user…), and origin, which was built from the Host / X-Forwarded-Proto headers, is no longer computed in getServerSideProps.
#5	js/request-forgery (critical)	pages/index.js (create profile)	✅ Fixed in d1f87aa: ${origin}/api/user → /api/user
#6	js/request-forgery (critical)	pages/index.js (delete profile)	✅ Fixed in d1f87aa: ${origin}/api/user?pid=… → /api/user?pid=${encodeURIComponent(pid)}
#7	js/request-forgery (critical)	pages/index.js (edit profile)	✅ Fixed in d1f87aa: same change as #6

Other issues I found:

• After bee0582 removed the origin prop, Bump axios from 0.21.1 to 0.21.2 #5, Fix dependency vulnurabilities #6 and removing yarn.lock to avoid dependency issues #7 were still using ${origin}. In the browser that name silently fell back to the global window.origin, so the page kept working but the alerts stayed open. All four requests now use same-origin relative URLs.
• bee0582 also broke lint: const { req } = context became unused (no-unused-vars), which would fail the Check Format + Lint CI step. I removed it.
• I also URL-encode searchString so a search containing & or = can't add extra query parameters.

Validation (local, on d1f87aa)

• npm run lint: passes, 0 warnings (it failed on bee0582)
• npm run format:check: all matched files use Prettier code style
• next build with .env.default: compiled successfully
• npm run init-db:default + npm test against a throwaway couchbase:enterprise-7.6.4 container: 4/4 suites, 6/6 tests passed
• Smoke test with next start: GET / → 200, GET /api/user?limit=2 → 200, GET /api/user?search=a%26b&limit=5 → 200. The page props are now just {"isConnected":true} (no origin).

CodeQL should close #5, #6 and #7 when it re-scans this branch.

[ejscribner]

@dex-the-ai can you also fix the test failure?

[dex-the-ai]

@ejscribner The tests (24.x) failure on d1f87aa wasn't caused by the code. The job failed at Initialize containers, before any of our steps ran, because public ECR throttled the Couchbase service image pull:

docker pull public.ecr.aws/z2f7n8a1/couchbase-da-containers:couchbase-neo
Error response from daemon: toomanyrequests: Data limit exceeded
##[error]Docker pull failed with exit code 1

I re-ran the failed job and it now passes: run 36739886147, attempt 2. Every step passed, including Check Format + Lint, and the unit tests reported Test Suites: 4 passed, 4 total and Tests: 6 passed, 6 total. All checks on the PR are now green. I didn't need to change any code.

(The failure before that, on bee0582, was a real lint error: 'req' is assigned a value but never used. d1f87aa had already fixed it.)

If ECR throttling keeps happening, we could pull the image from an authenticated registry or add a retry. I've left the workflow alone to keep this PR focused on the security alerts.