Request
The interface sends the information expected for the action.
Security · Validation and access
What the screen shows is not always the final decision.
In some workflows, MapMyStaff rechecks the fields, request types, routes, addresses, or rules required by that endpoint before continuing. Protected accounts use Firebase Authentication, some access controls rely on the user group, and anti-abuse protections can be added to configured web forms. Scope varies by module, endpoint, and version.
01Server validation
The browser proposes. The server can recheck what the workflow requires.
Risk addressed: a value or action shown in the interface should not replace the rules defined for that workflow.
Depending on the module, server-side validation can cover fields, request types, routes, addresses, or other rules before the workflow continues or records the result.
Scope limit: validations are specific to the endpoint and version. They do not automatically apply to every MapMyStaff action.
See server-validation details
Documented principle
Recheck
The server rereads what that endpoint requires.
Outcome
The workflow continues, rejects, or records according to its rules.
02Authentication and access
Protected workflows use configured authentication, and some access controls rely on the user group.
Firebase Authentication manages account authentication and session state for protected workflows that use that module.
Some documented access controls read the group attached to the user document, including administrator group 1 in the documented components.
Scope limit: effectiveness depends on deployed Firestore rules and consistent user documents. The complete roles-and-permissions matrix by collection and endpoint still needs to be completed.
See documented scope in the Trust Center
Confirmed controls
Protected account
Authentication and session state when the workflow uses Firebase Authentication.
Group-based access
Some components use the group in the user document to authorize access.
Scope
Deployed rules and configuration determine the control actually applied.
03Entry points and anti-abuse
Some configured web forms add anti-abuse controls before server processing.
Firebase App Check and reCAPTCHA Enterprise can be used on configured functions, including certain web forms.
Documented web requests can also use hourly counters based on an IP fingerprint and email address.
Scope limit: App Check and reCAPTCHA do not replace server-side validation, do not automatically apply to every call, and no rate limit eliminates all abuse.
Risk reduction
Application token
App Check depending on the function and configuration.
Anti-abuse signal
reCAPTCHA Enterprise on configured workflows.
Rate limiting
Documented hourly counters for certain web requests.
04Secrets and dependencies
Sensitive secrets are expected in the server environment, not in public scripts.
Sensitive keys are expected to remain outside the public repository and outside scripts delivered to the browser. Diagnostic logging should also avoid secrets and unnecessary information.
MapMyStaff documents dependencies on Google Firebase / Google Cloud, reCAPTCHA Enterprise, Postmark, and HERE or OSRM depending on the workflows used.
Scope limit: the quality and availability of some functions depend on the providers, keys, addresses, and services involved. Keeping a secret server-side is not an absolute security guarantee.
Review documented providers and limits
Documented dependencies
Firebase / Google Cloud
Hosting, authentication, Firestore, functions, and App Check depending on configuration.
Postmark
Transactional email for documented web forms.
HERE / OSRM
Geocoding and routes depending on the workflow.
Go further
Review the documented evidence and scope.
The Trust Center groups confirmed controls and items still to complete; the Architecture page details server-side validations.