Security

A secure goldsky-go integration keeps credentials distinct, limits their distribution, avoids logging sensitive URLs, verifies incoming webhooks before processing them, and treats retries for mutations as a business-risk decision. The SDK is designed to avoid placing secrets in error strings and default retry logs, but an application still controls deployment configuration, observability, and access policy.

Separate the credential types

Secret	Scope and purpose	SDK location	Storage rule
Project API token	Project-scoped REST control plane and private GraphQL authentication	First argument to NewClient	Store as an application secret; never embed in source or frontend code.
Edge endpoint API key	Specific Edge endpoint and JSON-RPC access	WithEdgeAPIKey or SetEdgeAPIKey	Store separately from the project token; do not log endpoint URLs.
Webhook delivery secret	Authenticity check for one webhook’s incoming deliveries	Stored by your HTTP receiver	Save at webhook creation; Goldsky returns it once if generated.

The project token is sent as an Authorization: Bearer header. The Edge key is carried in the RPC endpoint query string. That query-string design makes accidental URL logging particularly sensitive.1

Use least privilege and project isolation

Goldsky API tokens are scoped to a project. Keep production, staging, and development systems in separate project contexts where possible. Goldsky documents Viewer access for reads and Editor access for writes; use a token associated with the least capable role that serves the workload.2

Use distinct credentials for separate services when you need to revoke, rotate, or audit them independently. Do not share a production project token with browser code, sample repositories, CI logs, or third-party client-side monitoring.

Store, rotate, and inject secrets safely

Use a managed secret store in production. Inject values into the process at startup or use a controlled refresh mechanism. For local development, environment variables are acceptable if shell history, terminal output, and local .env files are protected.

client, err := goldsky.NewClient(
    os.Getenv("GOLDSKY_API_KEY"),
    goldsky.WithEdgeAPIKey(os.Getenv("GOLDSKY_EDGE_API_KEY")),
)

The SDK never logs the REST token or Edge key in its own errors. It can rotate the Edge key in place:

client.SetEdgeAPIKey(nextKey)

Rotating the REST project token requires constructing a new client with the new token and switching application dependencies deliberately. Do not attempt to modify unexported credential fields.

Treat one-time responses as secret material

Two management calls return sensitive values.

Call	Sensitive field	Handling
client.Webhooks.Create	CreateWebhookResponse.Data.WebhookSecret	Write to a secret manager immediately; it is not present in list responses.
client.Edge.Create	CreateEdgeEndpointResponse.Data.APIKey	Store immediately and distribute only to authorized RPC clients.
client.Edge.RevealKey	RevealEdgeKeyResponse.Data.APIKey	Restrict use to controlled recovery or rotation workflows.

Avoid returning these values from an administrative HTTP API. If a workflow needs to report success, report the resource name and secret-store reference, not the secret itself.

Secure outbound logs and telemetry

The following content can leak credentials or data and should be redacted before it reaches logs, traces, metrics labels, error reporters, or support tickets:

Data	Risk	Safe substitute
REST Authorization header	Project token disclosure	Header name only, or <redacted>.
Full Edge RPC URL	Includes ?key=<edge-key>	Log chain ID and endpoint name, not URL.
Webhook goldsky-webhook-secret header	Shared-secret disclosure	Header presence / verification result only.
GraphQL variables and payloads	May contain application data	Log operation name, duration, response status.
Raw error bodies	May contain resource or validation detail	Use only in controlled internal diagnostics.

If you install a custom http.RoundTripper, ensure it follows these redaction rules. The SDK can protect its own log messages but cannot control a caller’s generic HTTP instrumentation.

Authenticate webhook deliveries

Goldsky sends the literal goldsky-webhook-secret header. It does not document an HMAC signature for this webhook format. Use the SDK’s constant-time verifier, and reject requests before decoding or processing their bodies.

if !goldsky.VerifyWebhookRequest(r, storedSecret) {
    http.Error(w, "unauthorized", http.StatusUnauthorized)
    return
}

VerifyWebhookRequest uses crypto/subtle.ConstantTimeCompare, and an empty expected secret always fails. Add normal HTTP protections as well: TLS, a body-size limit, strict JSON decoding, a dedicated route, request rate limits, and durable idempotency keys. See Webhooks.

Retry safety is a security and correctness concern

By default, the SDK retries only safe REST reads. It does not retry mutations because Goldsky does not document idempotency keys. A transport timeout may mean the server processed a write but the client did not receive the response.

Before enabling WithRetryMutations, demonstrate how the application detects or tolerates duplicate create, pause, restart, deployment, and delete effects. The SDK never auto-retries streaming subgraph bundle deployments because an io.Reader cannot be safely replayed.

Configure timeouts and resource limits

Every call accepts context.Context. Set an operation-specific deadline to prevent a blocked outbound dependency from holding a server goroutine forever.

ctx, cancel := context.WithTimeout(r.Context(), 10*time.Second)
defer cancel()
response, err := client.GraphQL.QueryPrivate(ctx, projectID, name, tag, request)

For webhook receivers, use http.MaxBytesReader before JSON decoding. For pollers and list jobs, cap concurrency and page size. For public GraphQL, account for Goldsky’s documented rate limit instead of turning retries into a traffic amplifier.3

Incident response checklist

1. Revoke or rotate the exposed credential in Goldsky or the relevant managed secret.
2. Update the secret store and restart or refresh only the affected workloads.
3. Search logs, traces, CI output, issue trackers, and client-side bundles for the value or its URL form.
4. Inspect affected resource activity and application access logs.
5. Document the cause and add a redaction, scanning, or access-control safeguard.

Do not open a public issue with a suspected library vulnerability or a live secret. Use a responsible private reporting channel for security concerns.

References