Scribd
Upload
6 views2 pages

Code

This document outlines Firestore security rules for user profiles, app settings, and rewards. It specifies access permissions for reading, creating, and updating user profiles, emphasizing the need for Cloud Functions to secure financial operations. Additionally, it restricts updates to app settings and rewards to users with 'admin' or 'operator' roles while allowing public read access to certain data.

Uploaded by

siiirung
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
6 views2 pages

Code

This document outlines Firestore security rules for user profiles, app settings, and rewards. It specifies access permissions for reading, creating, and updating user profiles, emphasizing the need for Cloud Functions to secure financial operations. Additionally, it restricts updates to app settings and rewards to users with 'admin' or 'operator' roles while allowing public read access to certain data.

Uploaded by

siiirung
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd

rules_version = '2';

service [Link] {
match /databases/{database}/documents {

// Helper function to get user role


function getRole(userId) {
return get(/databases/$(database)/documents/users/$(userId)).[Link];
}

// WARNING: WITHOUT CLOUD FUNCTIONS, THESE RULES FOR USER-INITIATED FINANCIAL


OPERATIONS ARE A SECURITY COMPROMISE.
// A malicious user could bypass client-side logic to modify their
balance/points.
// For a production app, use Cloud Functions for 'setor', 'tarik', and 'redeem'
operations.

// --- User Profile Access ---


match /users/{userId} {
// Allow any logged-in user to read any user profile.
// This is necessary for the current leaderboard implementation to fetch
names and totalWasteKg of other users.
// PRIVACY CONCERN: This also grants read access to potentially sensitive
fields like email, balance, transactions
// if a client explicitly requests them. Consider a separate public_users
collection for leaderboard data for better privacy.
allow read: if [Link] != null;

// Users can create their own profile during registration


allow create: if [Link] != null && [Link] == userId;

// Allow users to update their own profile.


// This rule is lenient for 'balance', 'points', 'totalWasteKg',
'transactions', 'activeDays', 'lastActiveDate'
// because client-side functions (setor, tarik, redeem) directly update
these.
// The 'role' field CANNOT be changed by the user themselves.
allow update: if [Link] != null && [Link] == userId &&
[Link] == [Link];

// Admin can update ANY user's data, including sensitive fields and role.
// This bypasses the specific checks for self-updates above.
allow update: if getRole([Link]) == 'admin';
}

// --- App Settings (Waste Prices, Points Per Kg) ---


match /settings/app_config {
// Publicly readable for calculator, etc.
allow read: if true;
// Only Admin or Operator can write/update app settings
allow update: if [Link] != null && (getRole([Link]) ==
'admin' || getRole([Link]) == 'operator');
}

// --- Rewards ---


match /rewards/{rewardId} {
// Publicly readable by everyone
allow read: if true;
// Only Admin or Operator can create, update, delete rewards
allow create, update, delete: if [Link] != null &&
(getRole([Link]) == 'admin' || getRole([Link]) == 'operator');
}
}
}

You might also like