GCP Signed URLs Explained: Temporary Access to Private Cloud Storage Objects

What a signed URL is

A signed URL is a Cloud Storage URL that has been cryptographically signed by a service account. The signature encodes the allowed HTTP method (GET, PUT, etc.), the exact object path, an expiry timestamp, and other parameters. When a client makes a request using that URL, Cloud Storage verifies the signature, checks the expiry, and confirms the request matches the permitted method and path. No GCP credentials are required from the caller.

This makes signed URLs fundamentally different from normal Cloud Storage access. Normal access requires the caller to authenticate with Google and hold an IAM role on the bucket. A signed URL delegates that permission in a scoped, time-limited form to whoever holds the link.

Signed URLs are typically generated by your application server, which holds the service account credentials, and then given to clients on demand. The client uses the URL directly with Cloud Storage. Your server is not in the data transfer path.

For background on how Cloud Storage is structured and how normal access control works, see Storage Buckets Explained and Cloud Storage IAM vs ACLs.

Why signed URLs exist

Cloud Storage buckets are private by default. To read or write any object, a caller must have a valid GCP identity and an IAM role granting the relevant permission on the bucket. This is the right default for internal systems.

The problem is when you need to share a file with someone outside your GCP project. Consider these situations:

• A customer needs to download their invoice from a private bucket
• A mobile app needs to let users upload a profile photo directly to Cloud Storage
• A partner system needs to fetch a data export file once
• You want to email a one-time download link that expires in an hour

The obvious alternatives each have significant problems:

Signed URLs solve this cleanly. You grant temporary, scoped access to a specific object, for a specific HTTP method, with a specific expiry, without modifying any IAM policy or making anything permanently accessible.

How signed URLs work

Here is the full process from URL creation to the file being served:

1. Your server builds a canonical string containing the HTTP method, the full object path in the bucket, the expiry timestamp, and any required headers.

2. Your server signs the canonical string using a service account private key. The signature proves the URL was issued by a party with access to that service account.

3. The signature is appended to the URL as query parameters, along with the expiry time and the signing service account identity.

4. Your server returns the signed URL to the client via your API, an email, or however the client is consuming it.

5. The client makes an HTTPS request to the signed URL. No GCP credentials are sent. The URL itself is the credential.

6. Cloud Storage validates the signature using the public key for the signing service account, checks the request matches the permitted method and object path, and checks the expiry has not passed.

7. If everything is valid, Cloud Storage serves the object (for GET) or accepts the upload (for PUT). If not, it returns a 403.

The client never needs to know anything about GCP, IAM, or the service account behind the URL. The entire permission is encoded in the link.

Common use cases

• Customer download links. Generate a signed GET URL for an invoice, report, or receipt and include it in an email or API response. Set the expiry to match the expected download window.

• Direct browser or mobile uploads. Instead of routing a user’s file upload through your server, issue a signed PUT URL. The client uploads directly to Cloud Storage. Your server is removed from the data path entirely for large files.

• Sharing private exports. If you generate nightly reports or data exports into a private bucket, signed URLs let you share them with specific recipients without changing the bucket’s access policy.

• Partner system integrations. A partner API can fetch a file from your bucket using a signed URL your system generates on demand, without needing its own GCP credentials.

• Offloading transfers from your application server. Any time a file is large or a transfer is high-volume, signed URLs let clients connect directly to Cloud Storage rather than streaming through your application.

When to use signed URLs

Signed URLs vs other access methods

The key distinction between a signed URL and a public object is expiry and scope. A signed URL expires and is scoped to one specific object. A public object is accessible to anyone with its URL, indefinitely. Use signed URLs any time access should be temporary.

Compared to a backend proxy, a signed URL offloads the transfer entirely to Cloud Storage infrastructure. This is more efficient for large files but means your server has less visibility into exactly what is transferred. For strict audit requirements, proxying through your server may be preferable. For offloading transfer costs and reducing server load, signed URLs are better.

For browser form uploads specifically, Cloud Storage also supports signed policy documents. These allow more granular control over what a browser can upload (file size limits, content-type restrictions), whereas a PUT signed URL allows any bytes to be written to the specified path.

Creating signed URLs with gcloud

The gcloud storage sign-url command generates a V4 signed URL using the credentials of the current gcloud session or a specified service account. This is useful for testing and one-off operations. For production use, generate signed URLs programmatically in your application code.

# Signed URL valid for 1 hour to download a specific file
gcloud storage sign-url gs://my-app-private-assets/report-q1-2026.pdf \
  --duration=1h \
  --method=GET

# Signed URL valid for 15 minutes to upload a file (PUT requires content-type)
gcloud storage sign-url gs://my-app-uploads/user-123/avatar.png \
  --duration=15m \
  --method=PUT \
  --content-type=image/png

# Signed URL using service account impersonation (preferred pattern)
gcloud storage sign-url gs://my-app-private-assets/export.csv \
  --duration=30m \
  --method=GET \
  --impersonate-service-account=download-sa@my-project.iam.gserviceaccount.com

The —impersonate-service-account flag signs the URL on behalf of a service account without downloading its key file. This requires the iam.serviceAccounts.signBlob permission on that service account. See Service Account Impersonation for how impersonation works and when to use it.

Creating signed URLs in application code

In production, your application server generates signed URLs on demand and returns them to clients. The client then uses the URL directly with Cloud Storage. Your server is not in the data transfer path.

The upload workflow:

1. Client requests an upload URL from your server
2. Server generates a signed PUT URL for a specific, server-controlled object path and returns it
3. Client uploads the file directly to Cloud Storage using the signed URL
4. Cloud Storage validates the signature and stores the object
5. Client notifies your server that the upload is complete
6. Server validates the uploaded object (file type, size, content) before trusting it

The download workflow is identical but uses GET, and step 3 is a download rather than an upload.

from google.cloud import storage
import datetime

def generate_signed_download_url(bucket_name, object_name, expiry_minutes=60):
    """
    Generates a V4 signed URL for downloading a Cloud Storage object.
    When running on GCP infrastructure, the attached service account is used
    to sign via the IAM API. No key file is required.
    The service account must have iam.serviceAccounts.signBlob permission.
    """
    client = storage.Client()
    bucket = client.bucket(bucket_name)
    blob = bucket.blob(object_name)

    url = blob.generate_signed_url(
        version="v4",
        expiration=datetime.timedelta(minutes=expiry_minutes),
        method="GET",
    )
    return url


def generate_signed_upload_url(bucket_name, object_name, expiry_minutes=15):
    """
    Generates a V4 signed URL for uploading to a Cloud Storage object path.
    The client must send the same Content-Type header when uploading.
    """
    client = storage.Client()
    bucket = client.bucket(bucket_name)
    blob = bucket.blob(object_name)

    url = blob.generate_signed_url(
        version="v4",
        expiration=datetime.timedelta(minutes=expiry_minutes),
        method="PUT",
        content_type="application/octet-stream",
    )
    return url

When running on GCP (Cloud Run, GKE, Compute Engine), the client library uses the service account attached to the compute resource to sign via the IAM API. No key file is needed. This is the recommended approach and avoids managing private key material entirely.

For more on how service accounts work and what permissions they need, see Service Accounts. For how to upload files via the CLI rather than signed URLs, see Uploading Files with gsutil.

Security considerations

A signed URL is a credential. Anyone who has it can use it until it expires. Treat it accordingly.

• Use the shortest expiry that works. Minutes for one-time uploads, hours at most for downloads. A 7-day expiry on a sensitive file is a 7-day window for anyone who intercepts the URL.

• Scope to specific object paths. Never construct the object path from unvalidated user input. If user-controlled input reaches the path, a malicious client can request a signed URL for any object in the bucket. Build the path server-side from values you control.

• Validate uploads after completion. A signed PUT URL allows the client to write any bytes to that path. Validate the uploaded file’s type, size, and content server-side before treating it as trusted.

• Use IAM-based signing, not key files. The IAM signBlob API signs on behalf of a service account without a downloaded key file. Downloaded key files are a significant security liability. See Why Service Account Keys Are Dangerous for why the distinction matters.

• Use a dedicated service account for signing. Sign with a service account that has the minimum required permissions on the bucket, not with broad application credentials.

For access patterns that do not require external sharing, consider IAM Conditions to restrict access by time, resource, or request context instead of using signed URLs. See Cloud Storage Security for a broader look at bucket hardening.

If you are seeing unexpected 403 errors when using signed URLs, see Storage Access Denied Errors for common causes and fixes.