gcp-firestore-write-data
datastore.entities.create + datastore.entities.update together constitute effective full data-plane write access to Firestore/Datastore documents (overwrite capability).
match (effective permission)
{
"action": "datastore.entities.create",
"resource_type": "google.firestore.Database"
}
where
?principal ALSO has EFFECTIVE datastore.entities.update at the same database scope
emit
| source type | Identity |
|---|---|
| target type | Data |
| source | <principal> |
| target | <Firestore Database / NoSQLDatabase node> |
| permissions | datastore.entities.create datastore.entities.update |
| conditions | iam_permission resource_policy |
| state logic | ACTIVE when both datastore.entities.create and datastore.entities.update are confirmed effective at the project or database scope; CONDITIONAL(iam_permission) when one permission is uncertain; BLOCKED when VPC-SC or IAM deny blocks the write operations. Note: CanWriteData alone grants the ability to poison document content (e.g., inject malicious values or overwrite legitimate data), but does NOT grant code execution; further escalation requires a downstream trigger (Cloud Function reading Firestore) — modeled in gcf.yaml/eventarc.yaml. |
Narrative
{principal.name} holds datastore.entities.create and datastore.entities.update on {database.name} and can write or overwrite any document in the Firestore database (risk: data poisoning; downstream escalation if a compute resource consumes Firestore documents without validation).
Raw rule rules/derived/gcp/firestore.yaml
id: gcp-firestore-write-data
emits: CanWriteData
description: datastore.entities.create + datastore.entities.update together constitute effective full
data-plane write access to Firestore/Datastore documents (overwrite capability).
match_effective_permission:
action: datastore.entities.create
resource_type: google.firestore.Database
where:
- ?principal ALSO has EFFECTIVE datastore.entities.update at the same database scope
emit:
source_type: Identity
target_type: Data
source: <principal>
target: <Firestore Database / NoSQLDatabase node>
permissions:
- datastore.entities.create
- datastore.entities.update
conditions:
- iam_permission
- resource_policy
state_logic: "ACTIVE when both datastore.entities.create and datastore.entities.update are confirmed\
\ effective at the project or database scope; CONDITIONAL(iam_permission) when one permission is uncertain;\
\ BLOCKED when VPC-SC or IAM deny blocks the write operations. Note: CanWriteData alone grants the\
\ ability to poison document content (e.g., inject malicious values or overwrite legitimate data),\
\ but does NOT grant code execution; further escalation requires a downstream trigger (Cloud Function\
\ reading Firestore) \u2014 modeled in gcf.yaml/eventarc.yaml."
confidence: min(contributing_confidences) * 0.95
derived_from:
- datastore.entities.create + datastore.entities.update effective permissions on Firestore Database
false_positive_note: Write access to Firestore does not constitute code execution within Firestore itself.
Escalation via CanWriteData requires a secondary compute resource (Cloud Function / Cloud Run) that
reads the written data and is itself attacker-influenceable. Only emit CanWriteData for the data-plane
fact; defer the escalation derivation to the function/compute service rules. datastore.entities.delete
is a separate permission not required for write and is not included here (it enables data destruction,
not escalation). This rule requires BOTH permissions; for create-only injection capability, see gcp-firestore-inject-data.
narrative: '{principal.name} holds datastore.entities.create and datastore.entities.update on {database.name}
and can write or overwrite any document in the Firestore database (risk: data poisoning; downstream
escalation if a compute resource consumes Firestore documents without validation).'