security: isDevelopmentMode defaulting to "enabled" bypasses Firebase auth on misconfigured deploys

[oliursahin]

Summary

os.getenv("isDevelopmentMode", "enabled") in api_key_service.py means any deployment that omits this env var silently runs in development mode — bypassing Firebase authentication and GCP Secret Manager entirely, falling back to local Fernet-only key storage with no auth enforcement.

All other call sites in the codebase already use the safe pattern:

os.getenv("isDevelopmentMode") == "enabled"   # falsy/False when unset

This PR aligns api_key_service.py with that convention.

Change

- is_dev_mode = os.getenv("isDevelopmentMode", "enabled") == "enabled"
+ is_dev_mode = os.getenv("isDevelopmentMode", "disabled") == "enabled"

One character change. No logic change for deployments that explicitly set the env var either way.

Impact

Scenario	Before	After
isDevelopmentMode not set	dev mode ON (bypass auth)	dev mode OFF (correct)
isDevelopmentMode=enabled	dev mode ON	dev mode ON
isDevelopmentMode=disabled	dev mode OFF	dev mode OFF

Test plan

• Deploy without isDevelopmentMode set — GCP Secret Manager should be used, auth should be enforced
• Set isDevelopmentMode=enabled explicitly — behaviour unchanged (dev mode active)
• Set isDevelopmentMode=disabled explicitly — behaviour unchanged (dev mode inactive)

Summary by CodeRabbit

• Security
  • Development mode now defaults to disabled, requiring explicit enablement. This improves default security posture for API key management by adopting a more secure default configuration.

[coderabbitai]

Walkthrough

The development-mode detection logic in the API key service changes from defaulting to enabled to defaulting to disabled. Development mode now requires explicit opt-in via the isDevelopmentMode environment variable being set to "enabled" rather than defaulting to true when unset.

Changes

Cohort / File(s)	Summary
Development Mode Configuration app/modules/auth/api_key_service.py	Modified development-mode detection default from "enabled" to "disabled", making development mode opt-in rather than opt-out. The behavior for Secret Manager gating remains unchanged.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• API Key generated in local by falling back to local secret encryption env var #679: Modifies the same development-mode detection logic in api_key_service.py alongside adding local encryption fallbacks as an alternative to Secret Manager.

Suggested reviewers

• nndn

Poem

🐰 A toggle flips with gentle care,
Development mode now must declare!
"Enabled" spoken, secrets flow,
Otherwise they stay below. ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title describes a security issue about isDevelopmentMode defaulting behavior, but the actual change is inverting the default from 'enabled' to 'disabled' to fix a bypass—the title correctly highlights the security problem being resolved.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud