Seguridad
Ningún desarrollador tiene que acordarse de filtrar una consulta por organización. Un alcance global lo hace automáticamente, en cada modelo que lo necesita, así que un id caducado o adivinado de los datos de otra organización no resuelve nada, no una filtración.
Cada una cierra una forma distinta en la que una plataforma multi-tenant suele filtrar datos, en silencio, hasta que alguien se pone a buscar.
Un alcance global filtra cada consulta por organización en el momento en que un modelo arranca, sin nada que un desarrollador deba recordar y sin una sola consulta capaz de saltárselo, incluidas las que hay detrás de los enlaces de rutas.
El acceso de administración se verifica en cada solicitud, no solo al iniciar sesión, así que suspender una organización deja fuera a su equipo desde el siguiente clic. Sus productos dejan de ser accesibles públicamente en ese mismo instante.
Anular un ticket o cancelar una orden requiere su permiso específico, reverificado en el momento exacto de la acción, sin depender de qué permiso llevó a alguien hasta esa pantalla en primer lugar.
El costo y el margen nunca se escriben en una respuesta de tienda o de escaneo en puerta. No está oculto detrás de una bandera que alguien podría configurar mal más adelante: el campo directamente no existe en lo que se devuelve.
Cómo se sostiene
Cinco mecanismos, cada uno cerrando una forma distinta en la que el aislamiento suele romperse con uso real.
Un alcance global agrega el filtro de organización a cada consulta hecha sobre un modelo que lo lleva, aplicado en el momento en que el modelo arranca, sin ningún filtro que recordar y sin forma de que una sola consulta se lo salte.
Los enlaces de rutas dependen de ese mismo alcance, así que un enlace al registro de otra organización resuelve en un simple 404 antes de que se ejecute cualquier código del controlador, nunca en un error de permiso que confirmaría que el registro existe.
El alcance por sí solo protege lecturas y eliminaciones, pero no una escritura ciega hacia un id ajeno, así que un id que entra en una tabla pivote o en una columna de clave foránea se vuelve a resolver primero contra la consulta acotada de su propio destino.
Cada acción sensible vuelve a ejecutar una verificación de permiso en vivo contra la base de datos en el momento en que ocurre, no una sola vez al cargar la página, así que un permiso revocado a mitad de sesión deja de funcionar en el siguiente clic, no en el siguiente inicio de sesión.
Eliminar un producto, una opción o una categoría de ticket con ventas reales se rechaza dos veces: la capa de aplicación explica por qué antes de intentarlo siquiera, y la propia clave foránea de la base de datos está declarada para bloquear esa misma eliminación, así que un camino que se saltara la verificación seguiría fallando.
El detalle, tal cual
La respuesta que ve un escáner es una lista escrita a mano con exactamente lo que necesita el personal de puerta. El costo, el precio neto y el margen nunca se agregaron a ella, así que no hay nada que exponer por accidente más adelante.
{
"returned_to_gate_staff": {
"ticket_code": "AB12CD34EF",
"status": "redeemed",
"product_name": "City Food Tour",
"buyer_name": "Jane Buyer",
"position": 2,
"quantity": 3
},
"never_included": [
"cost_amount",
"net_amount",
"margin"
]
}El detalle que casi nadie explica
Una auditoría encontró ocho modelos accesibles adivinando un id de otra organización: seis relacionados con reglas de precios y disponibilidad, dos con asignaciones de impuestos. Ninguno llevaba su propio filtro de organización; cada uno lo heredaba de una relación padre que una consulta directa por un id enviado desde el cliente se saltaba por completo. Ahora cada uno lleva su propio id de organización, cerrando ese tipo exacto de brecha para siempre, y una suite de pruebas dedicada lo mantiene cerrado intentando exactamente ese mismo ataque, sobre los ocho, cada vez que la suite se ejecuta.
No. Cada modelo que lo necesita lleva un alcance global que filtra por organización automáticamente, lo cual también protege los enlaces de rutas: un id caducado o adivinado para el registro de otra organización resuelve en un 404, nunca en un error de permiso que confirmaría que el registro existe.
Su equipo de administración pierde el acceso al panel desde la siguiente solicitud, no solo desde el siguiente inicio de sesión, y sus productos dejan de ser accesibles a través de la API pública en ese mismo instante. La suspensión se aplica, no solo se registra.
Sí. Cada acción sensible reverifica el permiso en vivo contra la base de datos en el momento en que se ejecuta, no un rol guardado en caché desde que se cargó la página. El siguiente clic después de una revocación queda bloqueado.
No, y por partida doble. La capa de aplicación rechaza la eliminación con una explicación clara antes de intentarlo siquiera, y la propia clave foránea de la base de datos está declarada para restringir esa misma eliminación, así que incluso un camino que se saltara la verificación de la aplicación seguiría fallando.
No. Esas respuestas están escritas a mano para incluir solo lo que el destinatario realmente necesita. El campo nunca se escribe en la respuesta desde el principio, no está oculto detrás de una bandera que alguien podría configurar mal.
Tiqory mantiene disponibilidad, precios, pagos y acceso trabajando juntos mientras tu operación crece. Cuéntanos hacia dónde vas; te mostramos cómo llegar sin volver a empezar.