Seguridad

Validación de `postMessage`

Ambas cosas protegen contra el escenario donde otra página o iframe intenta inyectar mensajes o interceptar los tuyos.

Autenticación HTTP

El spec define que el partner expone:

GET {endpoint}/{interaction} (estado)
POST {endpoint}/{interaction}/events (webhooks)

Ambos llevan Authorization: Bearer <api_key>.

Dueño de la key. Vos la generás y sos el único que la valida en tus endpoints. Crowder la recibe durante la configuración de la aplicación embebida, la guarda en su dashboard y la reenvía tal cual en cada request. Crowder no la emite, no la rota y no tiene mecanismo de revocación remota: la key vale hasta que vos dejes de aceptarla.

Generación, formato y ciclo de vida quedan a tu criterio. Lo que sigue son las recomendaciones que te damos para esa decisión.

Lineamientos de creación

Entropía. Generala con un CSPRNG (≥ 32 bytes aleatorios). Evitá identificadores predecibles o derivados de datos de la ticketera.
Formato. String opaco, URL-safe (base64url o hex). Sin estructura semántica: Crowder no parsea el valor.
Alcance. Una key por integración partner ↔ ticketera. No reutilices la misma key entre ticketeras ni entre entornos (mantené sandbox y producción separados).
Transporte al compartirla con Crowder. Canal cifrado (gestor de secretos, vault compartido, mensaje cifrado). Nunca por email plano, chat sin cifrar, ni en el repo.
No la incluyas en el código del iframe — el iframe no la usa.

Operación

Serví bajo HTTPS con un certificado de CA pública.
Validá en tiempo constante para evitar leaks por timing.
No loguees en texto plano. Si necesitás trazabilidad, hasheá antes de persistir o imprimir.
Rotación. Generás una nueva key y la compartís con Crowder por el mismo canal seguro. Para evitar downtime, aceptá la key vieja y la nueva durante la ventana de cambio, y recién dá de baja la vieja una vez que Crowder confirme que actualizó su dashboard.
Revocación. Si la key se filtra, invalidala en tu backend de inmediato y compartí una nueva con Crowder. Hasta que Crowder cargue la nueva, los requests con la key comprometida deben fallar (401).

Datos del usuario

En context recibís user.email y opcionalmente user.firstName, user.lastName, user.country. Tratá esos datos según la normativa aplicable en la jurisdicción del evento (GDPR, Ley 25.326, LGPD, etc.).

Modelo de amenaza

Nada que venga por postMessage es autoritativo. Un atacante que controle el browser del usuario puede inducir a tu iframe a mostrar una oferta inconsistente con la reserva real.

Esto no tiene consecuencia económica porque, antes de generar la compra, Crowder llama tu GET de estado server-to-server y valida contra la fuente autoritativa de tu lado usando la interaction que vos generaste y guardaste.