OWASP REST Security Cheat Sheet

Skavio Processing API combines company-scoped keys, company-isolated jobs and authenticated result downloads. For an integration, the useful distinction is between a service that submits work and one that only retrieves it. Give each the access it needs, keep credentials server-side, and treat result delivery as part of the same access model.

1. Create the key around the integration’s job

Start in the company workspace with an administrator’s interactive, same-origin web session. Administrators create and revoke keys there; API keys cannot create other keys or initiate billing checkout. The documented scopes are read-only and read/write—not a separate write-only scope. Choose read-only for a consumer that needs only permitted reads, and read/write for an integration that submits processing work. Check the documented requirements for each operation rather than inferring permission from its HTTP method. Each key belongs to both a company and its creating member. Removing that membership invalidates the key’s access, so include member changes in your integration handover procedure.

Additional key policies can set expiry and permissions named read, upload, process and results.
These policies restrict the original scope; they cannot expand it.
An empty permissions list denies everything. A null permissions value restores the original scope’s behavior.
Policy changes require an administrator web session.

2. Store the secret server-side

The key secret is displayed once, and Skavio stores keys hashed at rest. Store the secret in a designated secret-management system and make it available only to the server-side services that need it. Authenticate over HTTPS using the Authorization: Bearer <API_KEY> request header. Do not put the API key in a URL, where it can enter server logs. Keep plaintext credentials out of source control, browser-delivered code and application logs. As an implementation recommendation, use a separate credential per integration rather than sharing one broad key across unrelated services. This makes replacement and access review more targeted; it is not an automatic Skavio feature.

Record each credential’s purpose, responsible team, company and intended permissions without recording its plaintext secret.
Keep submission credentials separate from retrieval credentials where the workflow allows.
Remember the billing boundary: web processing and API jobs share one company wallet, and job submission reserves the measured quote.

3. Rotate by replacing, testing and revoking

Treat routine rotation as a controlled deployment. Prepare and test a replacement credential, move consumers to it, verify their required operations, and then retire the old key. This is an operational procedure—not a promise of automatic rotation, a fixed overlap window or uninterrupted processing.

Create a replacement key through an administrator web session, with the required scope and restrictive policies.
Store its once-displayed secret securely.
Test the replacement against the integration’s actual operations, including result retrieval where required.
Update the consuming services and confirm they work with the replacement.
Revoke the old key through the administrator web session, then verify that the revoked credential is refused.

4. Follow the returned download path

After a job completes, use the download_path supplied in result.files. Do not construct a download URL from a filename. Request the documented API path with authentication, just as you would other protected API resources. Storage-backed result paths can return HTTP 307 redirects to short-lived signed URLs. This introduces a second boundary: authenticate to Skavio, but do not forward the Skavio key to storage. The signed storage URL needs no API key.

For curl, follow the official guide’s curl -L pattern and never add --location-trusted.
For other HTTP clients, explicitly prevent the Skavio Authorization header from being forwarded to the storage destination.
Treat signed download URLs as temporary access credentials; avoid exposing them in logs or public messages.
Do not assume revoking an API key also invalidates a signed URL already issued.
Keep signed-link lifetime separate from result retention; one does not establish the other.

5. Test refusals, not just successful requests

Before release, use synthetic files to verify that the intended read-only policy can perform the required polling and downloads while rejecting writes. Also test revoked-key refusal and cross-company isolation. These are recommended acceptance checks, not test results reported by this article. Use the documented status codes to distinguish authentication problems, permission restrictions and unavailable results. In particular, a 404 can represent a company boundary rather than simply a missing object. If a secret may have been exposed, prioritize immediate revocation and containment instead of keeping it active during the routine replacement sequence.

401: authentication is missing or invalid.
403: a scope or role restriction prevents the operation.
404: the object is absent or belongs to another company.
410: the result has expired.

A result download is part of the access model, not an exception to it.

Sources

Skavio Processing API — developer documentation — Documents key creation and revocation, read-only and read/write scopes, once-displayed secrets, hashed storage, company and member binding, authentication, result downloads and error responses.
Skavio — usage, budgets and recovery guide — Documents key expiry, restrictive read/upload/process/results permissions, empty versus null permission behavior, and administrator-session requirements.
Skavio — Storage Fabric integration guide — Documents HTTP 307 redirects to short-lived signed storage URLs and credential-safe redirect handling, including curl -L and the prohibition on --location-trusted.
OWASP Secrets Management Cheat Sheet — Supports least-privilege access, designated secret management, replacement-credential testing and the distinction between routine rotation and revocation after exposure.
OWASP REST Security Cheat Sheet — Recommends HTTPS and keeping API credentials out of URLs to reduce exposure through logs.

Create a key in your Skavio company workspace