Looker Studio Credentials and Security

Looker Studio’s credential model has security and cost implications that affect caching behavior, access control, and BigQuery billing attribution.

The Two Credential Modes

Owner’s credentials means all viewers access BigQuery through the dashboard owner’s identity. When someone opens your Looker Studio report, their browser makes API calls that are authenticated as you (or whatever account you used when creating the data source connection). BigQuery sees one identity regardless of whether 1 or 1,000 people view the report.

Viewer’s credentials means each viewer authenticates with their own Google account. BigQuery sees the actual identity of each person who opens the report. This requires viewers to have direct BigQuery access themselves, which adds IAM management overhead.

The LeakyLooker Vulnerability

In March 2026, Tenable published a security report they called “LeakyLooker” that demonstrated zero-click data exfiltration via public Looker Studio reports using owner’s credentials. The attack vector: a public report (accessible to anyone with the link) using owner’s credentials exposes the underlying data to anyone who can view the report — including people the owner never intended to share with, and without requiring the attacker to authenticate as anyone.

Because Looker Studio’s sharing settings and BigQuery’s access controls are independent, a report can be publicly shared even if the underlying BigQuery data is access-controlled. The owner’s credentials bypass BigQuery’s IAM entirely from the viewer’s perspective. Any data the owner can access, any viewer of a public report can extract by constructing the right chart configuration.

The implication for security policy:

1. Never use owner’s credentials on public reports. If a report is publicly accessible (anyone with the link can view), use viewer’s credentials so access is gated by the viewer’s own BigQuery permissions.
2. Audit your organization’s public reports. Go to Google Workspace Admin > Reports > Looker Studio, or run an audit through the Looker Studio Admin panel. Identify reports using owner’s credentials that are accessible outside your domain.
3. Use viewer’s credentials for any report containing sensitive or confidential data, even if it’s shared only within your organization.

Cost Attribution with Owner’s Credentials

The cost dimension is separate from security but equally important to understand. With owner’s credentials, all BigQuery queries from Looker Studio are billed to the credential owner’s project. If 200 people open a 10-chart dashboard, 2,000 BigQuery queries run against the owner’s billing account.

If your organization has multiple teams sharing dashboards and each team’s reports use their own owner’s credentials, costs are silently distributed across multiple projects with no central visibility. The engineering team’s dashboard costs show up in one project, the marketing team’s in another, and no one has a complete picture of how much Looker Studio costs overall.

You can track costs per report owner using INFORMATION_SCHEMA.JOBS filtered to Looker Studio’s query label:

SELECT
  user_email,
  COUNT(*) AS query_count,
  SUM(total_bytes_processed) / POW(1024, 4) AS total_tb_processed,
  SUM(total_bytes_processed) / POW(1024, 4) * 6.25 AS estimated_cost_usd
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND (
    SELECT l.value
    FROM UNNEST(labels) l
    WHERE l.key = 'requestor'
  ) = 'looker_studio'
GROUP BY 1
ORDER BY estimated_cost_usd DESC;

The user_email field here is the credential owner, not the viewer. This query tells you which report owners are generating the most BigQuery spend, which lets you identify the most expensive reports for optimization.

Using Service Accounts for Production Dashboards

The best practice for production Looker Studio dashboards is to use a dedicated service account as the credential owner rather than a personal account. This solves two problems simultaneously:

1. Organizational continuity: When a person leaves the organization, their personal account gets deactivated. Every report using their credentials breaks immediately — viewers see errors, data stops loading. With a service account, the report keeps working regardless of personnel changes.

2. Principle of least privilege: A personal account typically has much broader BigQuery access than any single dashboard needs. A dedicated service account can be granted exactly the permissions required for that report’s data sources and nothing more. If the service account’s credentials are misused, the blast radius is limited to the data that account can access.

Setting up a service account for Looker Studio:

1. Create a service account in the project where the data lives: looker-studio-prod@project.iam.gserviceaccount.com
2. Grant it roles/bigquery.dataViewer on the specific datasets or tables the dashboard needs
3. Grant it roles/bigquery.jobUser on the project where queries will run
4. In Looker Studio, when creating or editing the data source, choose “Service Account” as the credential type and upload the key file

For organizations managing multiple dashboards, consider a naming convention that makes service account purpose clear: ls-marketing-dashboard@project.iam.gserviceaccount.com vs. ls-ops-monitoring@project.iam.gserviceaccount.com. This makes IAM audits readable and access grants intentional.

The least privilege IAM patterns for GCP cover the broader approach, but the Looker Studio service account is one of the highest-ROI quick wins: it takes 20 minutes to set up, eliminates credential fragility, and provides cleaner cost attribution.

Viewer’s Credentials: When It’s Worth the Trade-Off

Viewer’s credentials means higher query volume (each viewer gets their own cache rather than sharing one), but it’s the right choice in specific scenarios:

• Row-level filtering by viewer identity: Each sales rep should see only their own accounts. With viewer’s credentials, BigQuery can enforce row-level security because the query runs as the actual user. With owner’s credentials, row-level security is impossible — the credential owner sees everything, and so does every viewer.
• Sensitive or regulated data: HR data, financial data, anything that requires access logging per-person. Viewer’s credentials ensures BigQuery’s audit logs show who actually accessed the data, not just the credential owner.
• Compliance requirements: Some regulations require that data access is logged and attributable to a specific individual. Viewer’s credentials satisfies this; owner’s credentials doesn’t.

If you use viewer’s credentials, plan for the higher query volume. Each viewer is effectively a new cache context. A dashboard with 100 daily viewers might generate 5-10x more BigQuery queries than the same dashboard with owner’s credentials and a shared cache. Set aggressive max_bytes_billed limits on the connection and consider BI Engine to keep per-query costs low even at higher volumes.