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

[hrshjswniii]

Problem Statement

---

The application currently determines administrative privileges using hardcoded email allowlists embedded directly within frontend source files.

Examples include:

const ADMIN_EMAILS = [...]

located in:

• src/pages/AdminDashboard.tsx
• src/pages/Resources.tsx

While this approach may provide UI-level access control, it should not be considered a secure authorization mechanism.

Administrative authorization should be enforced by trusted backend systems or database security rules rather than client-side code that is fully visible and modifiable by end users.

---

---

Security Risks

---

1. Administrator Information Disclosure

Because the admin allowlist is bundled into production JavaScript, any user can inspect browser DevTools, source maps, or compiled assets and retrieve administrator email addresses.

Potential consequences:

• Targeted phishing attacks
• Social engineering attempts
• Enumeration of privileged accounts

---

2. Authorization Logic Exists in an Untrusted Environment

Frontend code executes on the user's device and therefore cannot be trusted for security decisions.

Current logic:

ADMIN_EMAILS.includes(user.email)

can be bypassed through:

• Browser DevTools manipulation
• Modified client bundles
• Custom scripts
• Direct Firebase SDK usage

Even if the UI hides administrative controls, an attacker can still manually invoke database operations if backend rules are not enforcing equivalent restrictions.

---

3. Operational Maintenance Burden

Managing administrators through source code introduces unnecessary operational friction.

Current workflow:

Add Admin
→ Modify Code
→ Commit
→ Deploy
→ Wait for New Build

This creates avoidable overhead for routine role management.

---

---

Acceptance Criteria

---

• All hardcoded ADMIN_EMAILS arrays are removed.
• Administrative privileges are stored in Firebase Auth claims or Firestore.
• Firestore rules enforce admin-only operations independently of frontend code.
• Administrative actions remain inaccessible to non-admin users even when called directly through the Firebase SDK.
• Adding or removing administrators requires no frontend deployment.
• Existing admin workflows continue functioning without regressions.

---

---

Verification Plan

---

Authorization Testing

Non-Admin User

Verify:

• Cannot approve NGO requests.
• Cannot delete protected content.
• Cannot perform admin-only writes through direct SDK calls.

Expected Result:

PERMISSION_DENIED

---

Admin User

Verify:

• Administrative dashboard loads.
• NGO moderation actions succeed.
• Resource management operations succeed.

Expected Result:

Access granted

---

Security Validation

1. Build production assets.
2. Inspect bundled JavaScript.
3. Confirm no administrator email allowlists are present.

Expected Result:

No hardcoded admin identities exposed in client code.

---

---

Contribution Interest

---

Hiii @Piyushydv08 . I’d love to work on this issue and submit a PR implementing the offline detection flow as part of GSSoC'26
please assign this issue to me !!

[Piyushydv08]

Problem Statement

The application currently determines administrative privileges using hardcoded email allowlists embedded directly within frontend source files.

Examples include:

const ADMIN_EMAILS = [...]
located in:

• src/pages/AdminDashboard.tsx
• src/pages/Resources.tsx

While this approach may provide UI-level access control, it should not be considered a secure authorization mechanism.

Administrative authorization should be enforced by trusted backend systems or database security rules rather than client-side code that is fully visible and modifiable by end users.

Security Risks

1. Administrator Information Disclosure

Because the admin allowlist is bundled into production JavaScript, any user can inspect browser DevTools, source maps, or compiled assets and retrieve administrator email addresses.

Potential consequences:

• Targeted phishing attacks
• Social engineering attempts
• Enumeration of privileged accounts

2. Authorization Logic Exists in an Untrusted Environment

Frontend code executes on the user's device and therefore cannot be trusted for security decisions.

Current logic:

ADMIN_EMAILS.includes(user.email)
can be bypassed through:

• Browser DevTools manipulation
• Modified client bundles
• Custom scripts
• Direct Firebase SDK usage

Even if the UI hides administrative controls, an attacker can still manually invoke database operations if backend rules are not enforcing equivalent restrictions.

3. Operational Maintenance Burden

Managing administrators through source code introduces unnecessary operational friction.

Current workflow:

Add Admin
→ Modify Code
→ Commit
→ Deploy
→ Wait for New Build

This creates avoidable overhead for routine role management.

Acceptance Criteria

• All hardcoded ADMIN_EMAILS arrays are removed.[ ] Administrative privileges are stored in Firebase Auth claims or Firestore.[ ] Firestore rules enforce admin-only operations independently of frontend code.[ ] Administrative actions remain inaccessible to non-admin users even when called directly through the Firebase SDK.[ ] Adding or removing administrators requires no frontend deployment.[ ] Existing admin workflows continue functioning without regressions.

Verification Plan

Authorization Testing

Non-Admin User

Verify:

• Cannot approve NGO requests.
• Cannot delete protected content.
• Cannot perform admin-only writes through direct SDK calls.

Expected Result:

PERMISSION_DENIED

Admin User

Verify:

• Administrative dashboard loads.
• NGO moderation actions succeed.
• Resource management operations succeed.

Expected Result:

Access granted

Security Validation

1. Build production assets.
2. Inspect bundled JavaScript.
3. Confirm no administrator email allowlists are present.

Expected Result:

No hardcoded admin identities exposed in client code.

Contribution Interest

Hiii @Piyushydv08 . I’d love to work on this issue and submit a PR implementing the offline detection flow as part of GSSoC'26 please assign this issue to me !!

Assigned to u @hrshjswniii