Last updated: April 16, 2026
This document identifies potential attack vectors and mitigation strategies for data confidentiality, integrity, and availability for BigQuery. The scope of this report is limited to your perspective, focusing on risks that you can manage within your BigQuery environment.
These threat models are a probabilistic assessment based on currently known attack vectors, architectural assumptions, and the system's specified scope at the time of publication. These models are not exhaustive and are intended to serve as a baseline for Google Cloud customers' security and risk assessments and to guide risk reduction decisions.
The following threats were identified for this service:
- Data destruction using schema tampering
- Privilege escalation using IAM allow policy tampering
- Confused-deputy abuse using BigQuery-triggered downstream services
- Data exfiltration using unrestricted network egress
- Data integrity drift using poisoned reference or lookup tables
- Data tampering using malicious load jobs
- Excessive IAM permissions leading to information disclosure
- Exfiltration using a transfer to attacker-controlled cloud project or account
- Information disclosure using misconfigured authorized views or row-level security logic
- Information disclosure using public or cross-project dataset exposure
- Insider misuse of authorized BigQuery access (legitimate queries used for malicious collection)
- Persistence using stealth BigQuery IAM bindings on datasets, authorized views, or scheduled queries
- Spoofing using compromised service account credentials or OAuth token used for BigQuery access
- Cost-based denial of service using expensive queries
Threat details
The following sections provide information about each threat, their manifestations, and their recommended mitigations.
Data destruction using schema tampering
An attacker with permissions to modify a table's schema can cause potential data loss or render the table unusable for downstream applications. This form of tampering targets the metadata and structure of the data, which can be as destructive as modifying the data itself.
| STRIDE category | Tampering |
|---|---|
| MITRE ATT&CK tactic | Impact |
| Manifestations | Malicious schema update:A principal with the |
| Mitigations | Strictly limit the |
Privilege escalation using IAM allow policy tampering
An attacker who compromises a principal with permissions to modify BigQuery IAM allow policies can escalate their privileges to gain full control over data resources. This threat lets the attacker grant access to read, modify, or delete sensitive data, bypassing existing access controls.
Elevation of Privilege
Privilege Escalation
-
Dataset policy modification:A principal with the
bigquery.datasets.updatepermission can call thedatasets.patchAPI method on a BigQuery dataset to add their own identity to an owner role, granting them full control over all resources within that dataset. -
Service account impersonation:An identity with the
iam.serviceAccounts.actAspermission on a service account can attach the service account to other resources such as a Compute Engine instance to run code with the identity of the attached service account. Alternatively, an identity with theiam.serviceAccounts.getAccessTokenpermission can generate access tokens for that service account. If the target service account has elevated permissions on BigQuery resources, the attacker effectively inherits those privileges.
Strictly limit permissions that allow IAM allow policy modification (for example, bigquery.datasets.update
, which is part of roles like roles/bigquery.dataOwner
). Only assign these roles to a minimum number of trusted administrators. Similarly, tightly control the IAM roles with permission to act as or impersonate service accounts and scope these roles to specific principals that require it. Monitor Cloud Audit Logs for SetIamPolicy
and datasets.patch
API calls to detect unauthorized policy changes.
Confused-deputy abuse using BigQuery-triggered downstream services
An attacker with limited BigQuery permissions creates a job or query that triggers a downstream service (for example, Cloud Function, Dataflow job, or Cloud Composer DAG), which runs with higher privileges. The downstream service, while thinking it's performing a legitimate action on behalf of BigQuery, is tricked into performing an action on a different resource or with different data than intended by the system designers.
Elevation of Privilege
Privilege Escalation
-
Malicious function trigger:A BigQuery change triggers a Cloud Function that has broad permissions, and the attacker manipulates the BigQuery data to control the function's actions.
-
Dataflow pipeline exploitation:A BigQuery query result is used as input to a Dataflow job, and the attacker writes the query results to cause the Dataflow job to ingest poisoned data.
Apply the principle of least privilege to service accounts used by downstream services triggered by BigQuery. Ensure that these services validate and sanitize any inputs or parameters received from BigQuery jobs. Use VPC Service Controls to restrict the network pathways and service interactions. Design downstream services to not inherently trust inputs from BigQuery without verification.
Data exfiltration using unrestricted network egress
If network-level security controls aren't in place, a compromised internal principal can access BigQuery and exfiltrate sensitive data to an arbitrary location on the internet. Even with strong IAM controls, the absence of a network perimeter lets an attacker who has obtained valid credentials bypass location-based defenses and transfer data outside the trusted environment.
Information Disclosure
Exfiltration
-
API access from untrusted networks:An attacker uses compromised credentials to connect to the public BigQuery API or BigQuery Storage Read API from an external machine, bypassing network controls configured for on-premises hosts or user devices.
-
Export to an external Google Cloud service:A compromised service account with
bigquery.jobs.createand Cloud Storage permissions executes a query that exports results to a public Cloud Storage bucket outside the organization's control.
Implement network egress controls to mitigate data exfiltration to arbitrary external services. Implement a VPC Service Controls perimeter around the project that contains the BigQuery resources. This perimeter helps to restrict data exfiltration to Google Cloud services outside of the perimeter. Configure access levels for the perimeter to only allow API requests originating from trusted IP ranges or specific VPC networks, effectively preventing data from being accessed or moved outside the defined security boundary.
Data integrity drift using poisoned reference or lookup tables
An attacker with write access to reference or lookup tables (for example, dimension tables) subtly modifies their content. Queries joining with these poisoned tables produce incorrect, misleading results, compromising the integrity of analytics and business decisions downstream, potentially without any obvious errors.
Tampering
Impact
-
Dimension table manipulation:Changing key values or attributes in a product dimension table.
-
Lookup corruption:Altering mapping data in a lookup table.
Strictly limit write access ( bigquery.tables.updateData
) to reference or lookup tables to only trusted data ingestion processes. Implement data quality checks and validation pipelines. Use table snapshots or versioning to track changes and enable rollbacks. Monitor audit logs for changes to these critical tables.
Data tampering using malicious load jobs
An attacker with sufficient permissions can intentionally corrupt or overwrite critical data in a BigQuery table by executing a malicious load job. This threat compromises the integrity of the data, which can lead to incorrect business analytics, application failures, and loss of customer trust.
Tampering
Impact
-
Table overwrite:A principal with
bigquery.jobs.createandbigquery.tables.updateDatainitiates a load job with the write disposition set toWRITE_TRUNCATE, erasing all existing data and replacing it with malicious data from an external source. -
Malicious data appending:An attacker uses a load job with
WRITE_APPENDto inject garbage or malicious data into an existing table, corrupting analytics without deleting original records.
Apply the principle of least privilege. Tightly control permissions like bigquery.jobs.create
and bigquery.tables.updateData
(found in roles like roles/bigquery.dataEditor
). Grant these permissions only to trusted principals and scope them to specific datasets or tables. Monitor Cloud Audit Logs for load job completions, particularly those with a WRITE_TRUNCATE
disposition, and create alerts for jobs that originate from unexpected users or load data from untrusted sources.
Excessive IAM permissions leading to information disclosure
Overly permissive IAM roles might allow excessive access to sensitive data stored in BigQuery tables. An attacker who compromises a principal with broad data access permissions can exfiltrate large volumes of data, leading to a significant data breach. This threat is realized when permissions such as bigquery.tables.getData
or bigquery.jobs.create
are granted at a wide scope (for example, at the project level) instead of being restricted to specific datasets or tables required for a business function.
Information Disclosure
Exfiltration
-
Direct data read:A principal with the
bigquery.tables.getDatapermission can directly read data from tables using thetabledata.listAPI method or the high-throughput BigQuery Storage Read API. -
Query-based exfiltration:A principal with the
bigquery.jobs.createpermission can execute a query job usingjobs.insertorjobs.queryto read data from any table that they have access to and then retrieve the results usingjobs.getQueryResults. -
Public accessibility:An IAM allow policy on a BigQuery dataset or BigQuery table can be configured to allow public access by granting roles to special principals like
allUsersorallAuthenticatedUsers, exposing data to the internet.
Implement the principle of least privilege for all IAM allow policies. Grant permissions at the most granular level required (for example, specific BigQuery tables or datasets) rather than at the project level. Use least privilege IAM roles that contain only the necessary permissions (for example, bigquery.tables.getData
, bigquery.jobs.create
) for specific tasks. Regularly audit IAM allow policies for overly permissive roles like roles/bigquery.dataViewer
or roles/bigquery.user
applied at a high level in the resource hierarchy.
Exfiltration using a transfer to attacker-controlled cloud project or account
An attacker uses BigQuery's data movement capabilities (for example, export jobs to Cloud Storage, cross-project queries, BigQuery Data Transfer Service) to move sensitive data from the secured project to a Google Cloud project or other cloud account under their control.
Information Disclosure
Exfiltration
-
Export to external bucket:Using an export job to save table data to a Cloud Storage bucket in an attacker's project.
-
Cross-project query destination:Running a query and setting the destination table to a dataset in an attacker-controlled project.
Implement VPC Service Controls to create a perimeter around the project, preventing data egress to projects outside the perimeter. Tightly control permissions like bigquery.tables.export
and bigquery.jobs.create
. Use organization policy constraints to restrict project sharing and creation. Monitor Cloud Audit Logs for export jobs or queries with destinations outside the expected project boundaries.
Information disclosure using misconfigured authorized views or row-level security logic
Flaws in the SQL logic of authorized views or row-level security policies result in broader data access than intended. Users querying the view or table might inadvertently access rows or columns that they shouldn't be able to see, bypassing the intended segregation.
Information Disclosure
Collection
-
Faulty view logic:An authorized view's query omits necessary
WHEREclauses that are present in row-level security policies on the base table. -
Row-level security bypass:A complex row-level security policy contains a logical error that allows broader access than intended.
Implement a strict code review process for the SQL logic used in authorized views and row-level security policies. Test security logic thoroughly. Limit permissions (such as, bigquery.tables.create
, bigquery.tables.update
, or bigquery.rowAccessPolicies.create
) to create or update views and row-level security policies. Regularly audit existing views and row-level security configurations. Follow best practices for row-level security.
Information disclosure using public or cross-project dataset exposure
Sensitive data is exposed because BigQuery datasets are inadvertently or maliciously made public (for example, using allUsers or allAuthenticatedUsers) or shared too broadly with other Google Cloud projects outside the intended trust boundary. An attacker can directly access or copy the data without authentication or by using any authenticated Google account.
Information Disclosure
Exfiltration
-
Public dataset:An IAM allow policy on a dataset grants viewer permissions to
allUsers. -
Cross-project oversharing:A dataset is shared with an external organization or a service account in an untrusted project.
Implement the principle of least privilege for dataset IAM allow policies. Use organization policies such as constraints/iam.allowedPolicyMemberDomains
to restrict sharing to specific domains. Regularly audit dataset IAM allow policies using Security Command Center to detect public or overly broad permissions. Use VPC Service Controls to create perimeters around projects containing sensitive data to prevent unauthorized egress.
Insider misuse of authorized BigQuery access (legitimate queries used for malicious collection)
A malicious insider with legitimate access to BigQuery uses their authorized permissions to run queries and collect sensitive data for unauthorized purposes (for example, personal gain or espionage). While the access is authorized, the intent and use of the data are malicious.
Information Disclosure
Collection
-
Data hoarding:Regularly querying and downloading customer data beyond job requirements.
-
Sensitive analysis:Performing analyses to extract trade secrets or PII for exfiltration.
Enable and monitor Data Access audit logs to track data access patterns. Use tools like Sensitive Data Protection to scan query results for sensitive information. Implement User Behavior Analytics (UBA) to detect anomalous query patterns or data access volumes. Enforce clear data handling policies and provide security awareness training. Use row-level security and column-level security to limit data exposure even for authorized users.
Persistence using stealth BigQuery IAM bindings on datasets, authorized views, or scheduled queries
An attacker, having gained initial access, establishes long-term presence by creating hard-to-detect access mechanisms within BigQuery. This threat includes adding IAM bindings to datasets, creating authorized views that query sensitive data, or setting up scheduled queries that run under a privileged service account to exfiltrate data or maintain access.
Elevation of Privilege
Persistence
-
Hidden dataset IAM:Granting a personal account viewer rights on a specific, less-monitored dataset.
-
Authorized view backdoor:Creating a view authorized to access a restricted table, and granting access to the view.
-
Malicious scheduled query:Configuring a scheduled query to copy data to an external location periodically.
Regularly audit all IAM allow policies, including dataset-level permissions using tools like Security Command Center. Tightly control permissions for creating or updating datasets ( bigquery.datasets.update
), routines ( bigquery.routines.create/update
), and data transfers ( bigquery.transfers.update
).
Spoofing using compromised service account credentials or OAuth token used for BigQuery access
An attacker obtains service account credentials (for example, exported JSON keys) and uses them to authenticate to BigQuery as the compromised service account, inheriting all its permissions. This threat lets the attacker perform any actions the service account is authorized to do, such as reading data, running jobs, or modifying resources.
Spoofing
Initial Access
-
Leaked service account key:A JSON key file is exposed in code repositories, public storage, or instance metadata.
-
Compromised application:An application that uses a service account is compromised, allowing the attacker to extract and use its credentials.
-
Stolen OAuth token:An attacker intercepts or leaks an OAuth token from a client application or browser session.
-
Over-scoped token:An application requests and stores tokens with excessive scopes (for example, full BigQuery access when only read is needed).
Avoid exporting service account keys. Instead, use attached service accounts or Workload Identity Federation where possible. If keys are necessary, rotate keys regularly, and grant the service account only the minimum necessary permissions. Monitor Cloud Audit Logs and Security Command Center for anomalous service account activity or key exposure. Use the constraints/iam.disableServiceAccountKeyCreation
organization policy constraint to disable service account key creation. Securely store and transmit OAuth tokens. Follow OAuth 2.0 best practices. Request only the necessary scopes. Use short-lived tokens and refresh tokens securely. Implement mechanisms to detect and revoke compromised tokens. Monitor for anomalous token usage patterns. Complete standard service account key protection measures. Configure session length for Google Cloud services to enforce short-lived tokens and mitigate the risk of a leaked token.
Cost-based denial of service using expensive queries
An authenticated principal executes queries designed to consume excessive BigQuery resources (such as slots and bytes scanned). This threat can lead to massive cost overruns in on-demand projects or slot starvation for other users in reservation-based projects, hindering business operations.
Denial of Service
Impact
-
Unoptimized queries:Running queries with cross joins on large tables without filters.
-
Repetitive execution:Scripting frequent execution of costly queries.
Use BigQuery custom quotas to set user-level and project-level limits on query usage (for example, bytes scanned per day). Use the maximumBytesBilled
parameter in query jobs. Employ BigQuery reservations to isolate workloads and guarantee capacity. Configure billing alerts in Cloud Billing and monitor slot utilization in Cloud Monitoring to detect and react to anomalies.
