Firebase Authentication
Account authentication and session state on protected workflows that use this module.
Architecture and server-side validation
How does an action become a verified and recorded decision?
In documented workflows, the interface prepares a request, then server-side controls vary by module, endpoint, and version. They can validate fields, request types, routes, addresses, or rules before the workflow continues processing.
Reading modelNot a universal pipeline
1
RequestThe interface sends the information expected for the action.
2
EndpointExpected validations depend on the module and version.
3
Module processingWhat happens next depends on that endpoint’s documented behavior.
01Endpoint validation
Validations are not identical for every action.
The trust dossier confirms validation of fields, request types, routes, addresses, or rules depending on the module.
The key point is scope: validations are specific to the endpoint and version. A rule confirmed for one workflow should not be presented as active everywhere.
Limit: this page describes observed architecture; it is not an exhaustive list of every endpoint.
View security controls
Documented scope
1
FieldsPresence, format, or expected values depending on the action.
By endpoint2
Request typesThe expected type can be part of validation.
By endpoint3
Routes and addressesSome workflows validate a route or address.
By endpoint4
RulesApplied rules depend on the module and endpoint.
By endpoint02Identity and entry controls
The control applied depends on the workflow’s technical context.
Protected workflows can use Firebase Authentication. Some documented access controls rely on the group stored in the user document.
App Check and reCAPTCHA Enterprise can be added to configured functions. They do not replace server-side validation and do not automatically apply to every call.
Still to complete: the complete roles-and-permissions matrix by collection and endpoint is not presented as finalized.
Possible controls by workflow
Group-based access
Some controls read users/{uid}.groupId, including administrator group 1.
App Check / reCAPTCHA
Application token and anti-abuse signal for configured functions, including some web forms.
Anti-abuse limiting
Hourly counters by IP fingerprint and email are documented for web requests.
03Dependencies and services
External services act as dependencies for specific workflows.
The dossier documents Google Firebase / Google Cloud, reCAPTCHA Enterprise, Postmark, and HERE or OSRM. Their presence does not mean they all participate in every action.
For HERE / OSRM, quality depends in part on addresses, providers, keys, and service availability.
Governance: every new provider must be added to the register, assessed, and documented before activation.
Documented dependencies
FGoogle Firebase / Google Cloud
Hosting, authentication, Firestore, functions, and App Check depending on configuration.
RreCAPTCHA Enterprise
Anti-abuse signal associated with configured workflows.
PPostmark
Transactional emails for documented web forms.
HHERE / OSRM
Geocoding, routing, and fallback in documented workflows.
🔐
Secrets and logs
Sensitive keys are expected in the server environment, outside public scripts. Logs needed for diagnosis should avoid secrets and unnecessary information.
04Technical questions
Check what is confirmed — and what remains bounded.
This page intentionally stays focused on the structure of controls and dependencies. The Security page presents the risks addressed; the Trust Center groups evidence, scope, and items to confirm.
Open the Trust CenterScope questions
Why are checks not the same everywhere?
Because the trust dossier describes them by module, endpoint, and version. The fields, request types, routes, addresses, or rules to validate vary by action.
Do App Check or reCAPTCHA replace server-side validation?
No. The dossier explicitly states that these mechanisms do not replace server-side validation and do not automatically apply to every call.
Where should technical secrets be kept?
Sensitive keys are expected in the server environment, not in public scripts. Their operational management should remain outside the public repository.
Is the roles-and-permissions matrix complete?
No. The trust dossier states that the complete matrix by collection and endpoint still needs to be completed.
Go further
Connect the technical model to its documented scope.
The Trust Center shows what is confirmed and what still needs completion; the Security page summarizes the mechanisms in operational language.