# Services : Firebase : Security Rules
Applies to Database, Firestore, and Storage. Integrates with Auth.
---
When creating a database/firestore/bucket, choose Locked or Test mode.
- Locked mode — denies reads/writes from mobile & web clients (but not app servers)
- In Cloud Firestore and Realtime Database, the default rules for Locked mode deny access to all users.
- In Cloud Storage, only authenticated users can access the storage buckets.
- Test mode — anyone can read/write anything
---
With Realtime Database, rules work from top-down, with shallower rules overriding deeper rules.
- If a rule grants read or write permissions at a particular path, then it also grants access to all child nodes under it.
- However, `.validate` rules do not cascade. All validate rules must be satisfied at all levels of the hierarchy for a write to be allowed.
With Cloud Firestore and Cloud Storage, rules apply only at specified levels of the data hierarchy, and you write explicit rules to control access to different levels.
---
You can view and edit rules via CLI or console. Pick one method for editing and use it consistently. (ex: Storing rules in repo and using CLI to install them.)
---
Basic Use Cases
- Content-owner only: Restrict access to content by user.
- Mixed access: Restrict write access by user, but allow public read access.
- Attribute-based access: Restrict access to a group or type of user.
Database rules leverage JSON in rule definitions, while Firestore and Storage rules leverage a unique language built to accommodate more complex rules-specific structures.
---
All Rules across Firebase products have a path-matching component and a conditional statement allowing read or write access.
```
# Database
{ "rules": {
"<<path>>": {
// Allow the request if the condition for each method is true.
".read": <<condition>>,
".write": <<condition>>,
".validate": <<condition>>} } }
Path : The database location. This mirrors your database's JSON structure.
Request : These are the methods the rule uses to grant access.
The read and write rules grant broad read and write access,
while validate rules act as a secondary verification to grant access based on incoming or existing data.
Condition : The condition that permits a request if it evaluates to true.
```
```
# Firestore | Storage
service <<name>> {
match <<path>> {
allow <<methods>> : if <<condition>> } }
Request : The method or methods invoked in the allow statement. These are methods you're allowing to run.
The standard methods are: get, list, create, update, and delete.
The read and write convenience methods enable broad read and write access on the specified database or storage path.
Path : The database or storage location, represented as a URI path.
Rule : The allow statement, which includes a condition that permits a request if it evaluates to true.
```
Rules applied with "OR" semantics. If any rule matches path and conditions, access is granted. By default, if there isn't a rule allowing it, access at a path is denied.