Security Policies

Security policies provide row-level access control based on data relationships. They allow you to restrict access to records based on how they relate to the current user.

How It Works

Security policies evaluate access through relationship paths in your data. A user gains access to a record if they can reach it through an allowed path.

Example scenario:

Users → ProjectMembers → Projects → Tasks

A user can access tasks in projects where they are a member.

Setting Up Security Policies

1. Create a Relationship Path

Your collections need lookup properties that create a path from users to data:

tasks.project → projects
projects.members → users (via projectMembers)

2. Mark the Lookup Property

In the Developer Portal:

1. Navigate to your collection
2. Select the lookup property
3. Enable Security Policy on the property

3. Configure Access Rules

Set access rules that work with the security policy:

{
  "access": [
    { "method": "GET", "roleNames": ["_AUTHENTICATED_USER"] }
  ]
}

Access Evaluation

When a request is made:

1. The system identifies security policy properties on the collection
2. It traces relationship paths from the user to the requested record
3. Access is granted if a valid path exists where the user has the required role

PathFinder Tool

The Developer Portal includes a PathFinder tool to visualize and debug security policies.

Using PathFinder

1. Go to Security → Security Policy
2. Select a user to impersonate
3. View the access matrix showing:
   • Collections with security policies
   • Valid access paths for the selected user
   • HTTP methods allowed through each path

Reading the Access Matrix

Indicator	Meaning
Green	Access allowed
Red	Access denied
Path shown	The relationship chain granting access

Example: Project-Based Access

Consider a project management system:

Collections:

• users — Application users
• projects — Projects with a createdBy field pointing to users
• projectMembers — Links users to projects with a role field
• tasks — Tasks with a project lookup field

Security Policy Setup:

1. Enable security policy on tasks.project
2. Enable security policy on projectMembers.user and projectMembers.project

Result:

• Users can only see tasks in projects where they are members
• Access is determined by the projectMembers join collection
• Different member roles can have different permissions

Combining with Access Rules

Security policies work alongside access rules:

{
  "access": [
    { "method": "GET", "roleNames": ["_AUTHENTICATED_USER"] },
    { "method": "POST", "roleNames": ["manager", "project_lead"] },
    { "method": "DELETE", "roleNames": ["manager"] }
  ]
}

A user needs:

1. A matching role from the access rules AND
2. A valid security policy path to the record

Global Role Override

Users with global roles bypass security policy checks for methods where their global role has access. This is useful for:

• Admin users who need unrestricted access
• Support staff who need to view any record
• Service accounts with elevated permissions

Best Practices

• Keep paths short — Simpler paths are easier to understand and debug
• Use the PathFinder — Verify access works as expected before deploying
• Test with real users — Impersonate different user types to validate access
• Document your model — Record why each security policy exists