[Bug]: OpenSign Exposes a Hardcoded Parse Server Master Key

[28Hus]

Issue Description

OpenSign Exposes a Hardcoded Parse Server Master Key

Summary

OpenSign publishes a Master Key in .env.local_dev:

MASTER_KEY=XnAadwKxxByMr

Source: .env.local_dev

The backend passes MASTER_KEY directly to Parse Server:

masterKey: process.env.MASTER_KEY,
masterKeyIps: ['0.0.0.0/0', '::/0'],

Source: index.js

The published value can be supplied as X-Parse-Master-Key. A valid Parse
Server Master Key bypasses application ACL and class-level permissions and
provides privileged access to application data. Parse Server documents the
Master Key as an override for ACL and class-level permission checks:
Parse Server guide.

Additional deployment defaults

The Heroku application template provides another predictable Master Key:

"MASTER_KEY": {
  "description": "A key that overrides all permissions. Keep this secret.",
  "value": "myMasterKey"
}

Source: app.json

The App Engine template accepts a user-provided value but does not generate or
require a strong one:

MASTER_KEY: <your-master-key>

Source: app.yaml

Proof of concept

Run this only against a local OpenSign test instance using a local test
database. Do not send the published value to the hosted UAT or production
service.

Start OpenSign with the repository value and request a local Parse class:

curl -i \
  -H 'X-Parse-Application-Id: opensign' \
  -H 'X-Parse-Master-Key: XnAadwKxxByMr' \
  'http://127.0.0.1:8080/app/classes/_User?limit=1'

Expected result: the request is authorized by Parse Server and returns data
from the local _User class, even when the class ACL or class-level read
permission would deny an unauthenticated request.

The same request without the Master Key should be rejected or return only data
allowed by the local Parse security configuration.

The Master Key is also used by OpenSign server-side code for privileged
operations:

const masterkey = process.env.MASTER_KEY;

await axios.post(`${serverUrl}/users`, data, {
  headers: {
    'X-Parse-Master-Key': masterkey,
  },
});

Source: usersignup.js

Impact

Anyone who obtains XnAadwKxxByMr can authenticate to any reachable OpenSign
deployment that uses this value as its MASTER_KEY. The attacker can bypass
Parse ACL and class-level permissions and may read, modify, or delete
application data, depending on the exposed Parse routes and data classes.

The Heroku template value myMasterKey creates the same risk for deployments
that retain the template default.

The .env.local_dev file states that it connects to a hosted UAT backend. The
repository proves that the value is published and is wired into Parse Server;
this report does not claim that the current hosted UAT service still accepts
the value, because no request was sent to that service.

Remediation

• Revoke and rotate XnAadwKxxByMr immediately wherever it was used.
• Remove committed Master Keys from .env.local_dev and repository history.
• Remove myMasterKey from app.json.
• Require a deployment-specific, high-entropy MASTER_KEY at startup.
• Fail closed when MASTER_KEY is missing, short, or equal to a template value.
• Restrict masterKeyIps to trusted internal addresses instead of
  0.0.0.0/0 and ::/0.
• Audit access logs and database changes for use of the published values.

Expected Behavior

No response

Current Behavior

No response

Steps to reproduce

No response

Screenshots of the issue(optional)

No response

Operating System [e.g. MacOS Sonoma 14.1, Windows 11]

MacOS

What browsers are you seeing the problem on?

Chrome

What version of OpenSign™ are you seeing this issue on? [e.g. 1.0.6]

2.41.3

What environment are you seeing the problem on?

Dev (localhost or vercel)

Please check the boxes that apply to this issue report.

• I have searched the existing issues & discussions to make sure that this is not a duplicate.

Code of Conduct

• I agree to follow this project's Code of Conduct
• I have searched the existing issues & discussions to make sure that this is not a duplicate.