Skip to content
MapMyStaff
Help Centre · Security and data

Why can an action be rechecked server-side?

The dossier confirms server-side validation for certain fields, request types, routes, addresses, or rules. These validations are specific to the documented module, endpoint, and version.

Validation is not universal.A control observed in one endpoint should not be assumed to exist in every other flow.

The server may apply its own checks

In documented flows, the server may validate fields, the request type, a route, an address, or a module-specific rule. The result can therefore differ from a value prepared in the interface. The dossier states that these validations are specific to the endpoint and version.

01Scope

Distinguish three mechanisms

They all contribute to technical operation, but they do not have the same role and should not be confused.

Server validation

Check flow data and rules

The server may check fields, request types, routes, addresses, or rules depending on the module. Scope is specific to the endpoint and version.

App Check / reCAPTCHA

Add an anti-abuse signal

App Check and reCAPTCHA Enterprise are documented for configured functions, including Web forms. The dossier states that they do not replace server-side validation.

HERE / OSRM

Provide a specialized result

HERE and/or OSRM may be used for geocoding and routes depending on the flow. Quality depends on addresses, keys, and service availability, among other factors.

02Documented examples

Three contexts where controls differ

These examples show why the exact flow should be identified before concluding that a result is abnormal.

Web form

Anti-abuse and flow validation

Documented forms may use App Check or reCAPTCHA Enterprise in addition to server validation specific to the function.

Address / route

Specialized geocoding or routing

HERE and/or OSRM may be involved depending on the flow. The result depends on the supplied data and service availability.

Protected access

Authentication and deployed rules

A protected flow may depend on Firebase Authentication, a group control, and the Firestore rules actually deployed.

03Diagnosis

Document the exact flow

If the result is unexpected, record what helps reproduce the case without sending secrets or unnecessary personal information.

Journey and page

Record the exact journey and page used.

Account context

Indicate the account type or context without a sign-in identifier.

Attempted action

Precisely describe the action performed before the unexpected result.

Useful information

Keep only the non-sensitive elements needed to understand or reproduce the case.

Expected result

Explain what you expected to observe based on the journey and configuration.

Observed result

Copy the exact message and describe the actual behaviour obtained.

Date and sanitized evidence

Add the approximate date and time and a sanitized screenshot if it helps the diagnosis.

Security instruction: never send a password, authentication code, key, token, or secret.
Guardrails

What this article does not guarantee

This page describes mechanisms confirmed by component. It does not mean every action is revalidated in the same way.

  • An exhaustive list of every validation in the platform.
  • Identical server-side revalidation for every action.
  • That App Check or reCAPTCHA replaces server-side validation.
  • The absolute absence of errors, abuse, outages, or unexpected results.
Support

Document an unexpected result

If a validation produces a result you do not understand, note the flow, page, action, date, expected result, observed result, and exact message. Clean screenshots and do not send secrets.

Contact support

Did this page help you understand why a result may be rechecked?