Acceso público y URLs presignadas

Por defecto, un bucket de R2 es un cuarto cerrado: solo tu Worker y tus credenciales entran. Eso es correcto y prudente, pero tarde o temprano quieres que el mundo lea algo —un avatar, un PDF público, los assets de un sitio— o que un usuario suba un vídeo enorme sin que cada byte atraviese tu backend. Hay dos herramientas para abrir la puerta sin dejarla abierta de par en par. Los buckets públicos exponen su contenido tras un dominio. Las URLs presignadas reparten llaves temporales y acotadas para una sola operación. Ambas responden a la misma pregunta —cómo dejar que otros toquen tus bytes sin darles tus credenciales— con dos filos distintos.

Buckets públicos: el dominio como puerta

Un bucket privado solo se lee desde dentro de la confianza: tu Worker por binding, o un cliente con claves de acceso. Hacerlo público significa exponer sus objetos a internet por una URL, y R2 ofrece dos maneras que no conviene confundir.

La primera es un dominio propio. Conectas un dominio que gestionas en Cloudflare al bucket, y sus objetos quedan servibles bajo esa dirección. Esta es la vía de producción, y no solo por estética: al pasar por un dominio de tu zona, el bucket hereda toda la maquinaria del borde de Cloudflare —la caché para acelerar las lecturas repetidas, el WAF para filtrar tráfico, Cloudflare Access para exigir identidad, la gestión de bots—. El bucket deja de ser un almacén desnudo y se convierte en un origen con todas las defensas del edge delante.

La segunda es el subdominio r2.dev, una URL gestionada por Cloudflare que enciendes con un clic. Es cómoda para probar, pero está limitada por tasa y pensada solo para desarrollo: sin caché configurable, sin WAF, sin control de acceso. La regla es simple: r2.dev para trastear, dominio propio para servir de verdad. Y una cautela recurrente —si proteges el bucket con WAF o Access sobre tu dominio, acuérdate de desactivar el r2.dev, o dejarás una puerta trasera abierta que esquiva todas esas defensas—.

# Subir un objeto que luego servira un bucket publico tras tu dominio.
wrangler r2 object put mi-bucket/logo.png --file=./logo.png \
  --content-type=image/png --cache-control="public, max-age=31536000"

URLs presignadas: una llave con caducidad

El dominio público es para lo que quieres que cualquiera lea. Pero hay un caso distinto: dejar que una persona concreta haga una operación concreta durante un rato concreto —subir este vídeo, descargar aquel informe privado— sin darle credenciales ni abrir el bucket. Para eso está la URL presignada.

La idea es criptográficamente bonita. Tu servidor, que sí tiene las claves de acceso a R2, firma una URL que autoriza una operación específica sobre una clave específica, con una fecha de expiración incrustada en la firma. Entregas esa URL al cliente. El cliente la usa —un PUT para subir, un GET para descargar— hablando directamente con R2, que valida la firma y el plazo. Nunca viste las credenciales viajar; nunca abriste el bucket; la autorización cabe entera en una cadena firmada que caduca sola.

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";

const s3 = new S3Client({
  region: "auto",
  endpoint: `https://${env.ACCOUNT_ID}.r2.cloudflarestorage.com`,
  credentials: { accessKeyId: env.R2_KEY_ID, secretAccessKey: env.R2_SECRET },
});

// Firmar una URL que autoriza SUBIR una clave concreta durante una hora.
const urlSubida = await getSignedUrl(
  s3,
  new PutObjectCommand({ Bucket: "mi-bucket", Key: "usuarios/42/avatar.png", ContentType: "image/png" }),
  { expiresIn: 3600 },
);
// Devuelves urlSubida al cliente; el cliente hace PUT directo a R2.

Cambiando PutObjectCommand por GetObjectCommand firmas una descarga en vez de una subida: la misma mecánica sirve para repartir enlaces de descarga temporales a objetos que el bucket mantiene privados.

import { GetObjectCommand } from "@aws-sdk/client-s3";

// Firmar una URL que autoriza DESCARGAR un objeto privado durante cinco minutos.
const urlDescarga = await getSignedUrl(
  s3,
  new GetObjectCommand({ Bucket: "mi-bucket", Key: "facturas/2026-07.pdf" }),
  { expiresIn: 300 },
);

Sacar los bytes del camino del Worker

Reúne las dos ideas y verás para qué sirven de verdad. Sin URLs presignadas, si un usuario sube un vídeo de un gigabyte, ese vídeo tiene que atravesar tu Worker de camino a R2: tu código se vuelve una tubería por la que pasa cada byte, gastando tiempo y rozando límites. Con una URL presignada de subida, tu Worker solo hace una cosa —decidir si este usuario puede subir y firmar la llave— y el gigabyte viaja directo del navegador a R2, sin tocarte.

// El Worker autoriza y firma; no toca el fichero.
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const usuario = await autenticar(request, env);
    if (!usuario) return new Response("no autorizado", { status: 401 });
    const clave = `usuarios/${usuario.id}/${crypto.randomUUID()}`;
    const url = await firmarSubida(env, clave);   // devuelve una URL presignada
    return Response.json({ url, clave });
  },
} satisfies ExportedHandler<Env>;

flowchart LR
Cliente[cliente] --> Worker[worker firma la URL]
Worker --> Firma[URL presignada temporal]
Firma --> Cliente
Cliente --> R2[PUT directo a R2]
style Worker fill:#a6e3a1,color:#11111b
style R2 fill:#a6e3a1,color:#11111b