Cloud Storage Security and Static Sites

Four independent layers decide whether a request succeeds, and knowing which one produced a 403 is most of troubleshooting: organization policy (constraints such as storage.uniformBucketLevelAccess, storage.publicAccessPrevention and iam.allowedPolicyMemberDomains, several enforced in organizations created from 2024-05-03); public access prevention (a switch that rejects allUsers and allAuthenticatedUsers); IAM, with optional conditions, as the only mechanism once ACLs are off; and encryption plus VPC Service Controls (the caller must be allowed to use the key and be inside the perimeter).

The remaining sections follow that order. Everything that calls the API uses Application Default Credentials: the service account attached to Cloud Run, the Workload Identity Federation principal of a pipeline, or --impersonate-service-account on a developer machine (see Identity and Access). No page example downloads a service-account key.

A bucket created through the console today already follows most of the guidance below, and in a secure-by-default organization the rest is enforced for you. The settings to keep are:

Older guides (and gsutil acl ch -u AllUsers:R) make objects public with ACLs. That requires UBLA to be off and PAP to be off, and both are now blocked in new organizations. The current approach is IAM bindings on the bucket, and for anything public, a deliberate exception described in Hosting a static website.

Grant roles to the narrowest principal at the narrowest scope: a bucket (or a managed folder) rather than the project. The predefined roles you will use are:

Basic roles (Owner, Editor, Viewer) also contain Cloud Storage permissions at project level, and the legacy bucket roles (roles/storage.legacyBucketReader and friends) are added automatically to old buckets; neither belongs in a new design. Prefer the roles above. The full role list is in the Cloud Storage IAM roles reference.

Public access prevention stops accidental exposure. When it is enforced on a bucket, a request to add allUsers or allAuthenticatedUsers fails and existing public bindings stop working; when it is inherited, the organization policy constraints/storage.publicAccessPrevention decides. Treat a public bucket as the exception, reviewed and documented, and keep every other bucket at enforced.

A second control is easy to miss. Organizations created from 2024-05-03 enforce constraints/iam.allowedPolicyMemberDomains (domain-restricted sharing), which rejects any IAM binding whose principal is outside your organization — including allUsers. Even with PAP off, granting objectViewer to allUsers then fails with a policy error. Options are to exempt a specific project or folder by tag or by a narrower policy set by an organization administrator, or not to make the bucket public at all and serve the site with signed URLs or cookies through Cloud CDN (see Cloud CDN and Media CDN). See Resource Hierarchy and Projects for how policies inherit.

A signed URL gives anyone holding it temporary access to one object, with the permissions of the account that signed it, without a Google identity. Bookshelf uses them so the browser downloads a user’s upload (or uploads a cover) directly from Cloud Storage instead of streaming it through catalog-api.

Version 4 signing (HMAC is for interoperability, below) has these rules:

Every object is encrypted at rest with no action on your part. The three ways to control the key are:

For CMEK the bucket’s service agent needs roles/cloudkms.cryptoKeyEncrypterDecrypter on the key; the CLI creates the agent and grants the role in one command.

When data must not change or disappear for a period, use retention rather than permissions alone.

Browsers block cross-origin reads unless the server answers with CORS headers. When the Bookshelf front end at https://www.example.com loads fonts or JSON directly from a bucket, or uploads to a signed URL with fetch, the bucket needs a CORS configuration that names the origin, the methods and the response headers the page may read.

Derived from gcloud storage buckets update and the Configure cross-origin resource sharing (CORS) page. In the console the bucket’s CORS cannot be edited; use the CLI, Terraform (cors block) or the API. CORS applies to the XML API and to the JSON API calls the browser makes; it is not applied to requests served through the load balancer for the static site, where headers are set on the backend bucket (custom response headers) instead, see Cloud CDN and Media CDN. Keep origins explicit; "*" is rarely justified.

With requester pays the caller’s project, not the owner’s, is billed for transfer and operations, and every request must name a billing project (gcloud storage buckets update gs://BUCKET --requester-pays, then gcloud storage ls gs://BUCKET --billing-project=$PROJECT_ID). It suits shared datasets, does not work with anonymous access or signed URLs, and does not combine with the public site below. See the Requester Pays page.

IAM answers "who may call"; VPC Service Controls answers "from where". A perimeter around the project makes Cloud Storage reject calls whose source is outside the perimeter or outside an allowed access level, even with valid credentials, which limits data exfiltration with stolen tokens or misconfigured IAM. Create the perimeter in dry-run mode first and read the violations in the audit logs before enforcing.

Derived from gcloud access-context-manager perimeters dry-run create and the VPC Service Controls overview. Perimeters are created at the organization level and need Access Context Manager permissions; see Governance, Security and Compliance for the governance context. A perimeter also blocks a browser downloading through a signed URL from outside it unless an ingress rule or access level allows it, which is why the Bookshelf static bucket is normally kept outside the perimeter that guards the uploads bucket.

Cloud Storage can serve a site directly from a bucket, but with two limits that decide the design:

The current approach for a production site is therefore the global external Application Load Balancer with a backend bucket, a Google-managed certificate from Certificate Manager and, optionally, Cloud CDN on the backend bucket. The bucket stays the origin and the load balancer provides HTTPS, the anycast IP address, HTTP-to-HTTPS redirect and Cloud Armor if needed. Firebase Hosting is the simpler alternative for single page applications because it includes TLS, a CDN, rewrite rules and preview channels without a load balancer, at the price of a separate product and deploy tool.

The bucket website settings still matter behind the load balancer: MainPageSuffix is the file served for a directory-style request such as / and NotFoundPage is the object returned with a 404 status for a missing path. A single page application whose router uses real paths needs unknown paths to return index.html; setting NotFoundPage to index.html makes the app load but the status code stays 404, so use hash routing, a URL-map rewrite to the app shell, or Firebase Hosting rewrites when the status matters to crawlers.

Admin Activity audit logs (bucket and IAM changes) are always on and free. Data Access audit logs, which record who read or wrote which object, are off by default for Cloud Storage because they can be voluminous, and they are billed as log ingestion. Enable DATA_READ and DATA_WRITE for storage.googleapis.com on sensitive buckets only, and route them to a log bucket or BigQuery sink.

Derived from the Cloud Storage audit logging page and gcloud logging read. In the console use IAM & Admin → Audit Logs, filter for Google Cloud Storage, and tick Data Read and Data Write. Also look at the Security Command Center findings for public buckets, covered in Governance, Security and Compliance.

A single object name accepts roughly one write per second and bucket metadata or IAM updates are rate limited, so do not use one object as a counter. V4 signed URLs live at most 7 days, and bucket IAM policies, CORS and lifecycle configurations have size limits, so prefer groups and managed folders over thousands of individual bindings (see the quotas and limits page for current numbers). Behind the load balancer, Cloud CDN absorbs repeat reads, and forwarding-rule, proxy and URL-map quotas apply per project.

Prices change; use the Cloud Storage pricing page and the Google Cloud Pricing Calculator and note the date you looked. The security features on this page mostly add small cost drivers:

Delete in dependency order, in a throwaway project where possible. A bucket with a locked retention policy cannot be deleted until its objects age out, and soft-deleted objects remain recoverable (and billed) until their window ends.

Derived from gcloud storage rm, gcloud compute forwarding-rules delete and gcloud kms keys versions destroy. gcloud storage rm --recursive on a bucket removes the objects, every noncurrent version and the bucket itself; a bucket still under retention fails until the retention period of each object has passed. Soft-deleted objects can be listed with gcloud storage ls --soft-deleted and are purged when the soft-delete window ends. Key-version destruction is scheduled (24 hours by default) and the key ring and key resources remain, so no further charge accrues once the versions are destroyed. If the Firebase site was used, run firebase hosting:disable. Deleting the whole throwaway project removes everything at once (see Resource Hierarchy and Projects), after a 30-day recovery window.