Skip to content

Restrict access scope of master key #8218

Closed
@mtrezza

Description

@mtrezza

New Feature / Enhancement Checklist

Current Limitation

The masterKey currently allows to manipulate some Parse Server internal fields. At the same time, the masterKey is intended to be used for normal operations, such as for Parse Dashboard to connect to Parse Server or special Remote Config parameters. The scope of masterKey is unclear because it's not defined anywhere.

Allowing the masterKey to modify internal fields, while distributing it for normal operation is a bad combination. It raises the risk associated with a compromised masterKey, because it significantly increases the integrity impact of the vulnerability's CVSS score.

Feature / Enhancement Description

Define scopes, implement them and add them to docs. This will be a breaking change.

We can assume that there is a difference in scope between:

  • accessing all data within the official features and constrains of Parse Server (intended to be used for normal operation)
  • manipulating Parse Server internal fields that are usually rather constraint-free (not intended to be used for normal operation)

Suggested scopes:

Scope Internal data Custom data Restricted by CLP, ACL Key
Internal r/w r/w no maintenanceKey*
Master -/- r/w no masterKey
ReadOnlyMaster -/- r/- no readOnlyMasterKey
Session -/- r/w yes sessionToken

* doesn't exist yet as a feature

Example Use Case

  • give masterKey to a business client to access all data, configure dashboard apps and use Remove Config parameters that are restricted to master key --> this doesn't allow the user to mess up the internals of Parse Server
  • give maintenanceKey to a DevOp to be able to manipulate internal Parse Server fields --> these internal fields are not supposed to be manipulated for normal operation, they may need to to be manipulated for one-time migration or data correction tasks

Alternatives / Workarounds

n/a

3rd Party References

n/a

Metadata

Metadata

Assignees

No one assigned

    Labels

    block:majorNeeds to be resolved before next major release; remove label afterwardsstate:breakingBreaking change requires major version increment and `BREAKING CHANGE` commit messagetype:featureNew feature or improvement of existing feature

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions