01 / RESUMEN Y CONTRIBUCIÓN
Una unidad de análisis para el abuso que ya está dentro.
Las arquitecturas Backend as a Service reducen el tiempo necesario para construir autenticación, persistencia y APIs. Esa ventaja no vuelve insegura a la arquitectura. El problema de investigación aparece cuando controles diseñados para validar una etapa temprana se convierten, sin una revisión equivalente, en la frontera de confianza de un producto que ya opera con más usuarios, datos y automatización.
Observación respaldada
La literatura técnica sí establece dos piezas del problema: funciones legítimas pueden automatizarse de manera no deseada y una API puede conceder acceso incorrecto a funciones o flujos sensibles. Estas fuentes sostienen los conceptos relacionados; la conexión poblacional y acumulativa es la propuesta de ASID.
[R1][R4][R5]Propuesta ASID
ASID no describe un exploit concreto ni una debilidad exclusiva de un proveedor. Propone estudiar una secuencia posible: una población automatizada obtiene cuentas válidas, acumula suficiente confianza operativa y utiliza capacidades legítimas para degradar datos, contenido, métricas y reputación.
Propuesta ASID
Durante esa secuencia la infraestructura puede seguir disponible: las APIs responden, los tokens son válidos y cada petición aislada parece permitida. Lo que se degrada es la integridad del sistema y el supuesto que conecta una identidad autenticada con una intención legítima.
ASID EN UNA FRASEUna población automatizada de identidades sintéticas utiliza permisos legítimos para degradar una plataforma desde dentro.
| Vector | Facilitador | Resultado afectado |
|---|---|---|
| Identidades sintéticas coordinadas | Límites de confianza débiles | Integridad de datos, producto y reputación |
Propuesta ASID
02 / PREGUNTAS DE INVESTIGACIÓN
Cuatro preguntas delimitan el problema.
La investigación no parte de que ASID ya exista como una categoría empíricamente demostrada. Parte de una brecha analítica: varias decisiones pueden ser correctas de manera local y producir, al combinarse, una pérdida de control que ninguna alerta individual explica.
- 01
RQ1 — ¿Bajo qué condiciones una población de identidades legítimamente autenticadas puede producir daño coordinado sin comprometer credenciales?
- 02
RQ2 — ¿Qué decisiones de confianza y autorización permiten amplificar ese comportamiento dentro de interfaces legítimas?
- 03
RQ3 — ¿Qué combinación de señales permite diferenciar coordinación sintética de crecimiento o actividad legítima?
- 04
RQ4 — ¿Qué controles reducen el alcance, la persistencia y el costo de recuperar la integridad del producto?
Hipótesis
03 / LENGUAJE OPERATIVO
Identidad, acceso y confianza no son sinónimos.
Observación respaldada
NIST separa la prueba de identidad, la autenticación y la federación porque responden a garantías distintas. Para este análisis añadimos dos decisiones posteriores: la autorización contextual y la confianza operativa. La distinción evita atribuir a un token información que el token no contiene.
[R6]- 01
Identidad declarada: conjunto de atributos con los que una entidad se presenta ante el sistema.
- 02
Identidad autenticada: sesión que demostró posesión o control de un autenticador aceptado.
- 03
Identidad verificada: entidad que completó una comprobación definida, con alcance, nivel de garantía y vigencia determinados.
- 04
Acción autorizada: operación permitida sobre un recurso, propiedad o función bajo una política concreta.
- 05
Confianza operativa: decisión revisable de conceder una capacidad considerando contexto, comportamiento, volumen e impacto.
Observación respaldada
Una arquitectura de confianza cero no concede confianza implícita únicamente por ubicación, pertenencia o posesión de una cuenta. Desde la perspectiva de ASID, el mismo principio debe extenderse a la relación entre una sesión válida y una capacidad de producto.
[R7]
Autenticar valida credenciales. Confiar exige contexto y comportamiento.
05 / FRONTERAS Y SUPUESTOS
El adversario no necesita romper la puerta.
El modelo adopta una perspectiva deliberadamente restringida. El actor utiliza interfaces públicas u oficialmente disponibles; puede automatizar registros y operaciones, coordinar varias identidades y adaptar su ritmo. No se presupone acceso administrativo, ejecución remota de código, robo de sesiones ni compromiso del proveedor BaaS.
Capacidades asumidas
- 01
Crear o controlar múltiples identidades mediante el flujo normal de registro.
- 02
Completar verificaciones de baja fricción cuando sean automatizables o insuficientes para el riesgo de la acción.
- 03
Consumir APIs y funciones accesibles al cliente dentro de límites individuales plausibles.
- 04
Coordinar tiempo, contenido, infraestructura y objetivos entre identidades.
- 05
Observar respuestas del producto y ajustar el comportamiento para permanecer dentro de reglas locales.
Activos que pueden degradarse
- 01
Integridad y procedencia de perfiles, contenidos, relaciones y estados.
- 02
Calidad de búsqueda, recomendaciones, moderación y analítica.
- 03
Confiabilidad de cohortes, oferta, actividad y otras métricas de negocio.
- 04
Capacidad operativa para distinguir, aislar y recuperar actividad auténtica.
- 05
Confianza de usuarios, equipos internos y organizaciones conectadas.
| Dentro del modelo | Fuera del modelo | Razón |
|---|---|---|
| Abuso coordinado de capacidades legítimas | Explotación de memoria o ejecución de código | ASID estudia decisiones de confianza y autorización, no fallas de implementación de bajo nivel. |
| Identidades creadas o controladas por automatización | Robo de una cuenta concreta | El account takeover posee actores, evidencia y respuesta propias. |
| Degradación acumulativa de integridad | Indisponibilidad causada exclusivamente por saturación | El resultado principal es la pérdida de confianza, aunque pueda coexistir con consumo de recursos. |
06 / DEFINICIÓN FORMAL
Una secuencia observable de cuatro condiciones.
Propuesta ASID
Builker Labs define Automated Synthetic-Identity Defacement como un modelo conceptual para analizar la degradación coordinada de un sistema mediante una población de identidades sintéticas que obtiene acceso por mecanismos oficiales, recibe capacidades insuficientemente contextualizadas y utiliza esas capacidades para alterar la integridad percibida o verificable del producto.
- 01
Población sintética: identidades controladas o generadas de forma coordinada, con atributos plausibles y suficiente variación para evitar reglas triviales.
- 02
Confianza acumulable: capacidades que aumentan por registro, tiempo, actividad o verificaciones sin considerar adecuadamente comportamiento e impacto.
- 03
Acción legítima localmente: peticiones válidas para la cuenta y el endpoint, aunque su intención, escala o efecto agregado no lo sean.
- 04
Degradación acumulativa: pérdida de procedencia, calidad, explicabilidad o confianza que emerge de muchas acciones aparentemente pequeñas.
Población sintética
× confianza prematura
× capacidad automatizable
× impacto acumulable
→ riesgo de degradación ASIDPropuesta ASID
La cadena ASID
Población sintética, escalamiento de confianza, duplicación o contaminación y degradación de la plataforma.ASID se estudia como una secuencia de abuso, no como un exploit aislado.
07 / LA CADENA DE ABUSO
De una cuenta plausible a una crisis de producto.
La primera superficie afectada puede ser la percepción del negocio. Si el cliente influye en fechas, estados derivados o atributos de confianza, una población nueva puede parecer antigua, activa o madura. Registros, cohortes y actividad dejan entonces de describir adopción real, incluso antes de que aparezca contenido alterado.
Fábrica de identidades
Datos plausibles y automatización producen una población que puede confundirse con crecimiento orgánico.El poder no está en una cuenta aislada, sino en una población coordinada.
Una política que permite editar el propio perfil puede ser correcta a nivel de fila y equivocada a nivel de atributo. El JWT, la propiedad del registro y el contrato de la API pueden ser válidos mientras la decisión de negocio sigue siendo insegura. Proteger el objeto no implica proteger cada propiedad que cambia su autoridad.
La decisión equivocada
Una petición con JWT válido atraviesa una política permisiva y modifica un atributo que debería controlar el sistema.La petición puede ser válida mientras la decisión de autorización sigue siendo incorrecta.
Una copia aislada es moderable. Muchas variaciones repartidas entre identidades relacionadas pueden degradar búsqueda, recomendaciones y operaciones. El problema central deja de ser solo eliminar contenido: se vuelve reconstruir procedencia y distinguir qué objeto, propietario y relación fueron auténticos.
La confianza se convierte en distribución
Un objeto legítimo se transforma en múltiples copias con cambios pequeños en propietario, enlace, precio o contenido.La duplicación coordinada convierte ruido aislado en degradación estructural.
El daño también alcanza descubrimiento, reputación y operación. Usuarios activos, oferta, conversiones y cohortes dejan de representar comportamiento real; los equipos ya no saben qué conservar, aislar o eliminar. Restaurar disponibilidad puede ser rápido. Recuperar integridad exige reconstruir procedencia, relaciones y decisiones que antes parecían confiables.
Colapso de confianza
La contaminación se propaga desde los datos hacia la experiencia, la operación, las métricas y la reputación.El incidente deja de ser técnico cuando el producto ya no puede demostrar qué es auténtico.
08 / BACKEND AS A SERVICE
La velocidad amplifica decisiones de confianza.
BaaS no es inseguro por definición. El riesgo aparece cuando las decisiones provisionales del MVP —actualizaciones amplias, controles en el cliente o políticas genéricas— permanecen sin revisión mientras crecen el producto y la capacidad de automatización.
Observación respaldada
Row Level Security puede limitar qué filas alcanza una identidad, pero no reemplaza un modelo completo de autorización. Una política de propiedad puede funcionar exactamente como fue escrita y aun permitir cambios sobre atributos sensibles. La arquitectura debe decidir también qué propiedades son editables, mediante qué operación y bajo qué contexto.
[R3][R8]- 01
Campos públicos y sensibles conviven en el mismo modelo editable.
- 02
Una identidad autenticada recibe capacidades de alto impacto demasiado pronto.
- 03
Estados derivados de verificación, riesgo o reputación aceptan influencia del cliente.
- 04
Las operaciones críticas se ejecutan directamente contra APIs públicas sin mediación adicional.
- 05
El control considera peticiones individuales, pero no poblaciones coordinadas.
- 06
El volumen se limita de forma uniforme sin considerar el impacto de cada acción.
La automatización puede convertir una decisión débil y pequeña en una capacidad industrial.
09 / OBSERVABILIDAD
Una cuenta puede parecer normal. La población deja patrones.
Una identidad sintética bien formada puede permanecer dentro de los límites esperados para una cuenta. La señal aparece al cambiar la unidad de observación: relaciones entre cuentas, similitud de contenido, progresión de capacidades, infraestructura compartida y efectos acumulados sobre el producto.
Hipótesis
La coordinación no debe inferirse a partir de una señal única. La hipótesis operativa es que una combinación temporal de señales independientes —identidad, dispositivo, contenido, secuencia e impacto— puede aportar mayor capacidad discriminante que una puntuación aislada por usuario.
Indicadores de arquitectura
- 01
El cliente puede enviar atributos de verificación, reputación o confianza.
- 02
Las políticas protegen filas, pero no propiedades críticas.
- 03
Un token válido basta para operaciones de alto impacto.
- 04
Las cuentas nuevas pueden publicar, leer o modificar a gran escala.
- 05
No existe separación explícita entre identidad, reputación y autorización.
Indicadores de comportamiento
- 01
Registros que crecen sin actividad humana coherente.
- 02
Perfiles y contenidos con estructuras o variaciones repetidas.
- 03
Lecturas paginadas y sistemáticas de grandes conjuntos de datos.
- 04
Escalamiento acelerado desde registro hasta acciones de alto impacto.
- 05
Muchas identidades relacionadas por dispositivos, infraestructura o secuencias temporales.
- 06
Cambios pequeños distribuidos que producen un efecto agregado desproporcionado.
| Unidad observada | Pregunta | Riesgo de interpretación |
|---|---|---|
| Cuenta | ¿Esta acción se desvía de su historia? | Una cuenta nueva casi no tiene historia y una automatización lenta puede parecer normal. |
| Población | ¿Varias identidades comparten secuencia, contenido o infraestructura? | Usuarios legítimos pueden compartir redes, dispositivos o patrones culturales. |
| Producto | ¿El efecto agregado altera procedencia, calidad o distribución? | Un cambio de campaña o mercado puede producir variaciones legítimas similares. |
Señales de coordinación
Velocidad de creación, similitud de contenido, escalamiento de confianza, relación dispositivo-cuenta y lecturas masivas.Ejemplo conceptual de señales; no representa un producto ni datos operativos reales.
10 / DISEÑO DEFENSIVO
Separar identidad, permisos, reputación y comportamiento.
La defensa no depende de un control único. Reduce el espacio de abuso antes de la acción, limita su alcance durante la operación y conserva suficiente evidencia para recuperar integridad después de un incidente.
- 01
Tratar al cliente como una fuente no confiable para roles, verificación, riesgo, moderación y auditoría.
- 02
Proteger atributos sensibles, no únicamente la propiedad de la fila.
- 03
Aumentar capacidades de forma progresiva según contexto y comportamiento observado.
- 04
Aplicar límites según el impacto de la operación, no solo por número de peticiones.
- 05
Detectar coordinación entre identidades mediante similitud, infraestructura y secuencias.
- 06
Aislar acciones o poblaciones sospechosas sin destruir inmediatamente la evidencia necesaria para investigarlas.
- 07
Diseñar trazabilidad, procedencia y recuperación antes del incidente para restaurar integridad sin borrar actividad legítima.
| Momento | Objetivo | Capacidades |
|---|---|---|
| Antes | Reducir exposición y confianza prematura | Esquemas explícitos, privilegio mínimo, progresión de capacidades y controles por impacto. |
| Durante | Limitar propagación sin perder evidencia | Cuotas contextuales, aislamiento reversible, observabilidad poblacional y revisión humana. |
| Después | Recuperar integridad y aprender | Procedencia, historial inmutable, relaciones reconstruibles, rollback selectivo y análisis de causa. |
Recomendación defensiva
[R7]11 / PROPOSICIONES Y VALIDACIÓN
Un modelo útil debe poder equivocarse.
ASID se publica antes de contar con evidencia suficiente para estimar su prevalencia. Por eso sus afirmaciones centrales se expresan como proposiciones contrastables y no como hallazgos. Una evaluación futura debe poder apoyarlas, delimitarlas o mostrar que categorías existentes explican mejor el fenómeno.
Hipótesis
Hipótesis
Hipótesis
No autenticado → Sin acceso
Autenticado → AccesoDesconocido
↓
Autenticado
↓
Observado
↓
Verificado
↓
Confiable para una acción específicaProtocolo de evaluación propuesto
- 01
Construir simulaciones controladas con poblaciones sintéticas y datos que no pertenezcan a terceros.
- 02
Definir controles negativos con actividad legítima de forma, volumen y estacionalidad comparables.
- 03
Comparar señales individuales y poblacionales mediante precisión, cobertura, anticipación y explicabilidad.
- 04
Medir contención, pérdida de procedencia, reversibilidad y costo de recuperación, no solo bloqueo de peticiones.
- 05
Contrastar el modelo con casos anonimizados y revisión independiente cuando exista evidencia adecuada.
- 06
Registrar resultados que contradigan las proposiciones y revisar el alcance del modelo en lugar de conservar la etiqueta.
| Proposición | Evidencia que la apoyaría | Resultado que exigiría revisión |
|---|---|---|
| H1 | Acciones autenticadas de alto impacto requieren contexto adicional para discriminar riesgo. | La autenticación por sí sola mantiene discriminación consistente. |
| H2 | Controles por propiedad o función bloquean cambios que RLS de propiedad permite. | RLS aislada cubre los mismos escenarios sin controles adicionales. |
| H3 | Señales agregadas mejoran detección sin elevar de forma inaceptable falsos positivos. | No existe mejora frente al análisis individual. |
| H4 | Procedencia y aislamiento reducen tiempo y ambigüedad de restauración. | La recuperación no mejora frente a prevención equivalente. |
Confianza progresiva y contextual
Desconocido, autenticado, observado, verificado y confiable para una acción específica.La confianza no debería ser un estado universal: depende de la acción, el contexto y el impacto.
12 / MÉTODO, ÉTICA Y VALIDEZ
Lo que esta investigación puede —y no puede— sostener.
Propuesta ASID
El método combina modelado conceptual de amenazas y síntesis estructurada de documentación primaria. Se identificaron conceptos establecidos sobre amenazas automatizadas, identidad digital, autorización de objetos, propiedades y funciones, flujos sensibles, confianza cero y seguridad a nivel de fila. Después se analizaron sus relaciones y la brecha explicativa que aparece al observar una población coordinada en lugar de una petición aislada.
Proceso analítico
- 01
Delimitar el fenómeno sin asumir que constituye una categoría nueva.
- 02
Definir términos y separar garantías que suelen comprimirse bajo la palabra confianza.
- 03
Comparar el fenómeno con categorías establecidas y declarar sus solapamientos.
- 04
Explicitar actor, capacidades, precondiciones, activos, fronteras y exclusiones.
- 05
Descomponer la secuencia en movimientos observables y resultados acumulativos.
- 06
Formular proposiciones que puedan contrastarse o rechazarse mediante evaluación futura.
Su alcance son aplicaciones con registro abierto o de baja fricción, APIs accesibles desde clientes, contenido generado por usuarios y controles que evalúan cuentas de manera aislada. El modelo no afirma que todas esas condiciones produzcan ASID; identifica una superficie donde la combinación merece ser evaluada.
| Amenaza a la validez | Efecto posible | Tratamiento en esta edición |
|---|---|---|
| Validez de constructo | ASID podría superponerse demasiado con categorías existentes. | Se incluye una comparación explícita y un criterio para no utilizar el término cuando no añade poder explicativo. |
| Validez externa | El modelo podría no generalizar entre industrias y productos. | No se afirma prevalencia y se exige evaluación en contextos distintos antes de generalizar. |
| Sesgo de confirmación | Las señales elegidas podrían favorecer la hipótesis. | El protocolo exige controles negativos, resultados contradictorios y revisión independiente. |
| Daño por detección | La correlación poblacional podría afectar usuarios legítimos. | Se exige explicabilidad, aislamiento reversible, revisión y mecanismos de apelación. |
Límites declarados
- 01
No se ejecutaron pruebas contra sistemas de terceros ni se documenta un incidente específico.
- 02
No existe una estimación de prevalencia, frecuencia, impacto económico o superioridad de controles.
- 03
No se atribuye una debilidad a BaaS como categoría ni a un proveedor particular.
- 04
Las proposiciones son una agenda de investigación; no son resultados experimentales.
- 05
Las referencias respaldan conceptos relacionados, no la existencia previa del término ASID.
Recomendación defensiva
13 / PRINCIPIOS Y CONCLUSIÓN
El fantasma no está intentando entrar.
Siete decisiones para conservar integridad
- 01
El cliente solicita; el sistema decide.
- 02
Los atributos de confianza no son editables mediante operaciones generales.
- 03
Autenticarse no desbloquea automáticamente capacidades de alto impacto.
- 04
Los permisos consideran objeto, atributo, función, contexto, volumen e impacto.
- 05
La detección observa poblaciones además de cuentas individuales.
- 06
El sistema conserva la procedencia de sus datos y decisiones.
- 07
La recuperación de integridad se diseña antes del incidente.
En el modelo ASID, la identidad ya tiene cuenta, token y acceso a interfaces oficiales. El problema no es que haya roto la API: es que la arquitectura confundió identidad con confianza y una acción permitida con una intención legítima.
Una plataforma no pierde el control únicamente cuando deja de responder. También lo pierde cuando ya no puede explicar qué usuarios, datos y decisiones representan actividad auténtica. Disponibilidad sin integridad puede mantener el servicio en línea mientras el producto deja de ser confiable.
Propuesta ASID
La contribución de ASID no es afirmar que toda automatización sea adversarial ni que toda identidad sintética sea dañina. Es ofrecer una forma de preguntar dónde se acumula confianza, cómo se distribuye una acción válida y qué evidencia necesita una organización para recuperar el significado de sus datos.
ASID-001ASID no destruye necesariamente la infraestructura. Destruye la confianza en ella.
14 / TRAZABILIDAD Y REFERENCIAS
Una propuesta propia.
Fuentes identificables.
Estas fuentes respaldan conceptos de identidad, autorización y amenazas automatizadas relacionados con el análisis. No documentan ni validan previamente el término ASID, propuesto en esta publicación por Builker Labs.
No revisado por pares · Sin estimación de prevalencia
Actualizada el
Síntesis estructurada de documentación primaria
- R1
OWASP Foundation
Automated Threats to Web Applications
Taxonomía de usos automatizados no deseados que abusan de funciones legítimas. - R2
OWASP Foundation
API Security Top 10 — API1: Broken Object Level Authorization
Referencia sobre controles de autorización por objeto en APIs. - R3
OWASP Foundation
API Security Top 10 — API3: Broken Object Property Level Authorization
Distingue la autorización de un objeto de la autorización sobre sus propiedades sensibles. - R4
OWASP Foundation
API Security Top 10 — API5: Broken Function Level Authorization
Referencia sobre acceso a funciones no autorizado para un rol o grupo. - R5
OWASP Foundation
API Security Top 10 — API6: Unrestricted Access to Sensitive Business Flows
Explica cómo la automatización de flujos legítimos puede producir daño específico para el negocio. - R6
NIST
Digital Identity Guidelines — SP 800-63-4
Guías sobre prueba de identidad, autenticación y federación. - R7
NIST
Zero Trust Architecture — SP 800-207
Principios para evitar confianza implícita y proteger recursos mediante decisiones explícitas. - R8
PostgreSQL Global Development Group
Row Security Policies
Documentación oficial sobre políticas de seguridad a nivel de fila.
MATRIZ DE EVIDENCIA
| Pregunta | Afirmación evaluada | Base actual | Validación pendiente |
|---|---|---|---|
| RQ1 | Una sesión válida no equivale a intención legítima. | Identidad digital, amenazas automatizadas y propuesta ASID. | Simulaciones con poblaciones coordinadas y controles legítimos. |
| RQ2 | Objeto, propiedad y función requieren decisiones diferenciadas. | OWASP API1, API3 y API5; PostgreSQL RLS. | Comparación de arquitecturas y pruebas de política. |
| RQ3 | La población contiene señales que una cuenta aislada no muestra. | Hipótesis ASID y taxonomía de automatización. | Telemetría, controles negativos y análisis de falsos positivos. |
| RQ4 | Procedencia y recuperación reducen impacto acumulado. | Recomendación de diseño derivada del modelo. | Ejercicios de contención, restauración y medición de costo. |
CÓMO CITAR
Builker Labs. (2026). “El fantasma dentro de la API: ASID y el sabotaje automatizado mediante identidades sintéticas en arquitecturas BaaS” (ASID-001, versión 1.0).
No se ha asignado DOI a esta publicación.
HISTORIAL
v1.0Edición pública completa: preguntas, método, modelo de amenaza, proposiciones y agenda de validación.