security: inject session credentials into API requests

[cfsmp3]

Summary

• Add authentication middleware that injects credentials from session into request body
• Prevents credential manipulation by overwriting any user-provided values
• Makes frontend credential storage optional while maintaining backward compatibility

Security Issues Addressed

Encryption Secret Exposed to Frontend (High) and Missing Authorization on API Endpoints (High)

Previously, the frontend stored and sent credentials (email, UUID, encryption_secret) with every API request. Users could potentially manipulate these values to access other users' tasks. This PR addresses both issues by:

1. Injecting session credentials into request body (overwriting any provided values)
2. Frontend no longer needs to send sensitive credentials (they're still displayed in SetupGuide for local taskwarrior configuration)

Note: This PR supersedes #407 as it uses a more secure approach (inject vs validate)

Changes

• backend/middleware/auth.go: New authentication middleware that:

  • Validates user has an authenticated session
  • For POST requests, injects session credentials into request body
  • Overwrites any user-provided credentials
  • Returns 401 Unauthorized if no session

• backend/main.go: Apply auth middleware to task endpoints

Test plan

• Test task operations work correctly with valid session
• Verify unauthenticated requests are rejected (401)
• Verify credentials in request body are ignored (session values used)
• Verify SetupGuide still displays credentials for local taskwarrior setup

🤖 Generated with Claude Code

[github-actions]

Thank you for opening this PR!

Before a maintainer takes a look, it would be really helpful if you could walk through your changes using GitHub's review tools.

Please take a moment to:

• Check the "Files changed" tab
• Leave comments on any lines for functions, comments, etc. that are important, non-obvious, or may need attention
• Clarify decisions you made or areas you might be unsure about and/or any future updates being considered.
• Finally, submit all the comments!

More information on how to conduct a self review:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request

This helps make the review process smoother and gives us a clearer understanding of your thought process.

Once you've added your self-review, we'll continue from our side. Thank you!

[its-me-abhishek]

Previously, the frontend stored and sent credentials (email, UUID, encryption_secret) with every API request. Users could potentially manipulate these values to access other users' tasks

Probably needs to update the frontend, in order to completely test this. The backward compatibility could be a grey area, making it seem to work. Though instead of injecting this directly via auth, one better way could be to just validate the session upon a login or request, and re construct the Secrets on its own, using utils, if not provided by frontend (remove them from frontend calls as well). So one may or may not provide those creds, if not, generate on your own using the authenticated session else just use the provided values

[cfsmp3]

Thanks for the feedback! I want to make sure I understand your concern correctly.

The current implementation overwrites any credentials in the request body with session values (not just injects when missing):

// middleware/auth.go lines 66-70
bodyMap["email"] = sessionEmail
bodyMap["UUID"] = sessionUUID
bodyMap["encryptionSecret"] = sessionSecret

This means it's already backward compatible:

Scenario	What happens	Security
Frontend sends credentials	Overwritten with session values	✓ Secure
Frontend sends no credentials	Session values injected	✓ Secure
Attacker sends manipulated credentials	Overwritten with session values	✓ Secure

Example attack scenario the PR prevents:

1. User A logs in (session has uuid: "user-a-uuid")
2. Attacker intercepts and modifies request body to {"UUID": "user-b-uuid", ...}
3. With "accept if provided" approach → Uses attacker's value → Vulnerable
4. With current "overwrite" approach → Uses "user-a-uuid" from session → Secure

If we used your suggested approach ("if credentials provided, use them; if not, generate"), the vulnerability would still exist because attackers could just keep sending manipulated credentials.

Unless you meant: validate that provided credentials match the session, and reject if they don't? That would also be secure, but the overwrite approach is simpler and has the same security properties.

The frontend can be updated to stop sending credentials at any time - the backend will work either way. No coordination needed.

Am I missing something in your suggestion? Happy to discuss further if you see an issue with this approach.