[Security] : Replace Client-Side Hardcoded Admin Authorization with Server-Enforced Access Control

[hrshjswniii]

#Program

GssoC'26

---

---

🏷️ PR Type

---

Type of PR (check one):

• 🐞 Bug Fix
• ✨ Feature
• 🛠️ Improvement / Refactor
• 📚 Documentation

---

---

🔗 Related Issue

---

• fixes issue [Security] : Replace Client-Side Hardcoded Admin Authorization with Server-Enforced Access Control #159

---

---

📝 Rationale / Motivation

---

• What problem does it solve?
  • Resolves information disclosure of admin emails inside production JavaScript bundles.
  • Ensures administrative access control cannot be bypassed by client-side code modification or DevTools tampering.
  • Removes structural database dependency on hardcoded values.
• How does it improve the project?
  • Moves all administrative authentication rules to trusted database-side checks (firestore.rules).
  • Supports adding or removing administrators dynamically via Firestore without redeploying the frontend.
• Any relevant context for reviewers.
  • Before testing or deploying, administrators must be registered under the new admins Firestore collection where the Document ID is the administrator's lowercase email.

---

---

✨ Description of Changes

---

Summarize changes with details:

• Frontend
  • src/components/Navbar.tsx refactored: Removed the hardcoded ADMIN_EMAILS array and checked dynamic administrative credentials from the admins collection on authentication change.
  • src/pages/Resources.tsx refactored: Removed ADMIN_EMAILS array and checked dynamic credentials to toggle partner deletion access.
  • src/pages/AdminDashboard.tsx refactored: Removed ADMIN_EMAILS and enforced dynamic collection check. Renders an "Access Denied" view if the signed-in user lacks administrator records.
• Backend / API
  • Created firestore.rules defining access rules for all database collections (admins, profiles, stories, reactions, reports, ngos, ngo_requests, testimonials).
  • Enforced server-side administrator checks using OIDC token details verification against the admins database collection.
• Documentation
  • Created database rules template mapping for deployment.

---

---

🧪 Testing Instructions

---

Step-by-step guide to test this PR:

1. Setup or dependencies:
   • Install dependencies using npm install.
   • Seed a test email in the Firestore admins collection (Document ID: lowercase email).
2. Actions to perform:
   • Sign in as an administrator; check that the moderation links, dashboard statistics, and deletions function as expected.
   • Sign in as a regular user; confirm that the navigation links are hidden, /admin renders "Access Denied", and write operations are blocked.
3. Expected results:
   • Access is granted to verified admins.
   • Non-admins receive PERMISSION_DENIED on database operations.
4. Automated tests coverage:
   • Built production assets (npm run build) to ensure TypeScript compilation passes.
5. Verify edge cases:
   • Tested cases where users are logged out or their emails contain uppercase letters.

---

---

👀 Impact Assessment

---

Analyze the impact of this PR:

• User-facing changes (UI / UX): Admin navigation elements are shown/hidden dynamically.
• Backend/API changes: Strict collection read/write boundaries enforced via firestore.rules.
• Performance considerations: A minor getDoc call is triggered upon login/auth state updates.
• Security implications: Significantly hardens application security; removes administrator information leakage and resolves bypass vulnerabilities.
• Cross-browser / device impact: Fully compatible across browsers.

---

---

⚡ Checklist

---

• Code follows project’s coding style and guidelines
• Changes are tested locally
• Automated tests added/updated
• Documentation updated (if applicable)
• User-facing changes are documented
• Related issue linked
• No new warnings/errors introduced
• All reviewers guidance addressed

[netlify]

👷 Deploy request for safevoiceforwomen pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	e7f8f00

[Piyushydv08]

#Program

GssoC'26

🏷️ PR Type

Type of PR (check one):

• 🐞 Bug Fix
• ✨ Feature
• 🛠️ Improvement / Refactor
• 📚 Documentation

🔗 Related Issue

• fixes issue [Security] : Replace Client-Side Hardcoded Admin Authorization with Server-Enforced Access Control #159

📝 Rationale / Motivation

• What problem does it solve?

  • Resolves information disclosure of admin emails inside production JavaScript bundles.
  • Ensures administrative access control cannot be bypassed by client-side code modification or DevTools tampering.
  • Removes structural database dependency on hardcoded values.

• How does it improve the project?

  • Moves all administrative authentication rules to trusted database-side checks (firestore.rules).
  • Supports adding or removing administrators dynamically via Firestore without redeploying the frontend.

• Any relevant context for reviewers.

  • Before testing or deploying, administrators must be registered under the new admins Firestore collection where the Document ID is the administrator's lowercase email.

✨ Description of Changes

Summarize changes with details:

• Frontend

  • src/components/Navbar.tsx refactored: Removed the hardcoded ADMIN_EMAILS array and checked dynamic administrative credentials from the admins collection on authentication change.
  • src/pages/Resources.tsx refactored: Removed ADMIN_EMAILS array and checked dynamic credentials to toggle partner deletion access.
  • src/pages/AdminDashboard.tsx refactored: Removed ADMIN_EMAILS and enforced dynamic collection check. Renders an "Access Denied" view if the signed-in user lacks administrator records.

• Backend / API

  • Created firestore.rules defining access rules for all database collections (admins, profiles, stories, reactions, reports, ngos, ngo_requests, testimonials).
  • Enforced server-side administrator checks using OIDC token details verification against the admins database collection.

• Documentation

  • Created database rules template mapping for deployment.

🧪 Testing Instructions

Step-by-step guide to test this PR:

1. Setup or dependencies:

   • Install dependencies using npm install.
   • Seed a test email in the Firestore admins collection (Document ID: lowercase email).

2. Actions to perform:

   • Sign in as an administrator; check that the moderation links, dashboard statistics, and deletions function as expected.
   • Sign in as a regular user; confirm that the navigation links are hidden, /admin renders "Access Denied", and write operations are blocked.

3. Expected results:

   • Access is granted to verified admins.
   • Non-admins receive PERMISSION_DENIED on database operations.

4. Automated tests coverage:

   • Built production assets (npm run build) to ensure TypeScript compilation passes.

5. Verify edge cases:

   • Tested cases where users are logged out or their emails contain uppercase letters.

👀 Impact Assessment

Analyze the impact of this PR:

• User-facing changes (UI / UX): Admin navigation elements are shown/hidden dynamically.
• Backend/API changes: Strict collection read/write boundaries enforced via firestore.rules.
• Performance considerations: A minor getDoc call is triggered upon login/auth state updates.
• Security implications: Significantly hardens application security; removes administrator information leakage and resolves bypass vulnerabilities.
• Cross-browser / device impact: Fully compatible across browsers.

⚡ Checklist

• Code follows project’s coding style and guidelines
• Changes are tested locally
• Automated tests added/updated
• Documentation updated (if applicable)
• User-facing changes are documented
• Related issue linked
• No new warnings/errors introduced
• All reviewers guidance addressed

When I log in using these three specific email accounts, I can access the Admin Dashboard, which is used to manage NGO and stories.

In your implementation, where have you configured or added these admin email addresses? Also, there is no need to add Firestore security rules in the PR, as those rules are already configured in the Firestore console.