Object Storage - Browser-based uploads using POST

Objective

This guide explains how to implement browser-based direct uploads to OVHcloud Object Storage using the HTTP POST method, with server-side POST Policy generation and SigV4 authentication.

Requirements

• A Public Cloud project in your OVHcloud account
• An Object Storage user already created
• AWS CLI installed and configured

Instructions

Overview

Browser-based POST uploads allow web applications to let end users upload files directly to an OVHcloud Object Storage bucket, without routing file data through your application server. Your backend generates a policy and signature, the user selects a file, and the browser sends the upload directly to the bucket.

The upload flow consists of the following steps:

1. Your backend generates a POST Policy (a JSON document defining upload constraints) and signs it with a SigV4 HMAC-SHA256 signature.
2. Your HTML page contains a form embedding the policy, signature, and object metadata as hidden fields.
3. The user selects a file and submits the form.
4. The browser sends the multipart/form-data POST request directly to the OVHcloud Object Storage endpoint.
5. OVHcloud validates the policy, verifies the signature, and stores the object.
6. The browser receives a response: an HTTP redirect or a status code depending on your form configuration.

# virtual-hosted style
https://<bucket_name>.s3.<region>.io.cloud.ovh.net/

# path style
https://s3.<region>.io.cloud.ovh.net/<bucket_name>

Objects written via POST are immediately visible in the bucket (strong read-after-write consistency). The maximum object size per POST upload is 5 GB.

Configure bucket CORS

Browser POST uploads always trigger a CORS preflight (OPTIONS) request before any data is sent. Without a matching CORS rule on the bucket, the browser blocks the upload silently.

Save the following JSON to a file named cors.json:

{
  "CORSRules": [
    {
      "AllowedOrigins": ["https://your-application.com"],
      "AllowedMethods": ["POST"],
      "AllowedHeaders": ["*"],
      "ExposeHeaders": ["ETag", "x-amz-version-id"],
      "MaxAgeSeconds": 3000
    }
  ]
}

Then apply it to your bucket:

aws s3api put-bucket-cors --bucket <bucket_name> --cors-configuration file://cors.json

Explanations:

• --bucket <bucket_name>: replace with the name of your bucket.
• --cors-configuration file://cors.json: path to the CORS configuration file.

Generate the POST Policy

The POST Policy is a UTF-8 JSON document generated server-side. It defines the constraints that OVHcloud validates before accepting the upload. The document must be base64-encoded before being placed in the form.

Policy structure

{
  "expiration": "2026-07-07T12:00:00.000Z",
  "conditions": [
    {"bucket": "<bucket_name>"},
    ["starts-with", "$key", "uploads/"],
    {"x-amz-algorithm": "AWS4-HMAC-SHA256"},
    {"x-amz-credential": "<access_key>/20260706/<region>/s3/aws4_request"},
    {"x-amz-date": "20260706T000000Z"},
    ["content-length-range", 1, 10485760]
  ]
}

Explanations:

• expiration: mandatory ISO 8601 timestamp in GMT. The policy is rejected with HTTP 403 once this time has passed. Evaluated against the OVHcloud server time.
• conditions: every form field included in the request (except x-amz-signature, file, and policy itself) must have a matching condition in this array.
• content-length-range: restricts the accepted file size in bytes (here, 1 byte to 10 MB).

Condition types

Conditions

Calculate the SigV4 signature

The signature is computed server-side using HMAC-SHA256. The input to the signature is the base64-encoded policy document.

Step 1 - Encode the policy

Encode the policy JSON as a UTF-8 byte string, then base64-encode those bytes. The resulting string is both the policy form field value and the input to the signature (StringToSign).

Step 2 - Derive the signing key

dateKey              = HMAC-SHA256("AWS4" + <secret_key>, <date>)
dateRegionKey        = HMAC-SHA256(dateKey, <region>)
dateRegionServiceKey = HMAC-SHA256(dateRegionKey, "s3")
signingKey           = HMAC-SHA256(dateRegionServiceKey, "aws4_request")

Explanations:

• <secret_key>: the secret access key of your Object Storage user.
• <date>: signing date in YYYYMMDD format (for example: 20260706). Must be within 7 days of the OVHcloud server's current date.
• <region>: OVHcloud region identifier (for example: gra, rbx, bhs). Must match the region used in x-amz-credential.
• HMAC-SHA256 inputs and outputs are raw bytes, not hex strings, at every intermediate step.

Step 3 - Calculate the signature

signature = hex( HMAC-SHA256(signingKey, StringToSign) )

The result is a lowercase hexadecimal string. Use this value as the x-amz-signature form field.

Build the HTML upload form

The upload form must use method="POST" and enctype="multipart/form-data". The action attribute must be the virtual-hosted bucket URL.

Example form

<form action="https://<bucket_name>.s3.<region>.io.cloud.ovh.net/"
      method="POST"
      enctype="multipart/form-data">

  <!-- Required authentication fields -->
  <input type="hidden" name="key"               value="uploads/${filename}">
  <input type="hidden" name="policy"            value="<base64_encoded_policy>">
  <input type="hidden" name="x-amz-algorithm"  value="AWS4-HMAC-SHA256">
  <input type="hidden" name="x-amz-credential" value="<access_key>/20260706/<region>/s3/aws4_request">
  <input type="hidden" name="x-amz-date"       value="20260706T000000Z">
  <input type="hidden" name="x-amz-signature"  value="<hex_signature>">

  <!-- Optional fields (examples) -->
  <input type="hidden" name="Content-Type"              value="image/jpeg">
  <input type="hidden" name="success_action_status"     value="201">
  <input type="hidden" name="x-amz-meta-uploaded-by"   value="user-123">

  <!-- File field must always be last -->
  <input type="file" name="file">
  <button type="submit">Upload</button>
</form>

Required form fields

Optional form fields

Handle responses

Success responses

If success_action_redirect is set and the upload succeeds, the browser is redirected to that URL. The query parameters bucket, key, and etag are appended automatically. success_action_redirect takes priority over success_action_status when both fields are present.

Error responses

On failure, OVHcloud returns an S3-compatible XML error body:

<Error>
  <Code>AccessDenied</Code>
  <Message>...</Message>
  <RequestId>...</RequestId>
</Error>

Common error conditions:

Server-Side Encryption (SSE)

SSE-S3 - OVHcloud-managed key

To request server-side encryption with an OVHcloud-managed AES-256 key, add the following hidden field to the form:

Add the corresponding condition to the POST Policy:

{"x-amz-server-side-encryption": "AES256"}

SSE-C - customer-provided key

To encrypt the object with a key you provide, add the following three fields to the form. All three must have corresponding conditions in the POST Policy.

Versioning behaviour

The versioning state of the target bucket affects the upload response:

For more information, see the Object Storage - Getting Started with Versioning guide.

Go further

For training or technical assistance implementing our solutions, contact your sales representative or visit our Professional Services page to request a quote and have your project analysed by our experts.

Join our community of users.

¹: S3 is a trademark of Amazon Technologies, Inc. OVHcloud's service is not sponsored by, endorsed by, or otherwise affiliated with Amazon Technologies, Inc.