¿Qué son los Permisos a Nivel de Clase (CLPs)?

Un permiso a nivel de clase es una regla en el esquema de una clase que controla qué usuarios o roles pueden ejecutar cada operación en esa clase. Es el gate más externo de la seguridad en la capa de datos: antes de cualquier verificación por fila, la propia clase decide si este solicitante puede consultar, crear, actualizar o eliminar ahí — una regla, la tabla entera, verificada primero.

Puntos clave

El gate de la clase, declarado y sentido

Una CLP es configuración de esquema — aquí el payload REST que bloquea una clase Config en lectura pública y escritura solo desde el servidor:

PUT /schemas/Config
{
  "classLevelPermissions": {
    "find":   { "*": true },              // cualquiera puede consultar
    "get":    { "*": true },
    "create": {},                         // nadie desde el lado del cliente
    "update": { "role:admin": true },     // solo admins
    "delete": {},
    "addField": {}                        // esquema congelado
  }
}

Lo que los clientes experimentan es el gate haciendo su trabajo — las lecturas fluyen, las escrituras mueren en la frontera de la clase antes de tocar dato alguno:

// JavaScript / Node.js — Back4app JS SDK
// The class gate in action: Config is read-only for clients (CLP),
// so reads succeed and writes never reach the data
const config = await new Parse.Query('Config').first(); // ✓ public read

const c = new Parse.Object('Config');
c.set('flag', true);
try {
  await c.save(); // ✗ CLP blocks client writes to this class entirely
} catch (e) {
  console.log(e.code); // 119: operation forbidden by class-level permissions
}

// Flutter / Dart — Back4app Flutter SDK
// The class gate in action: reads allowed, client writes blocked by CLP
final config = ParseObject('Config')..set('flag', true);
final response = await config.save();
if (!response.success) {
  print(response.error?.code); // 119: forbidden by class-level permissions
}

// iOS / Swift — Back4app Swift SDK
// The class gate in action: reads allowed, client writes blocked by CLP
var config = Config()
config.flag = true
config.save { result in
  if case .failure(let error) = result {
    print(error) // operation forbidden by class-level permissions
  }
}

// Android / Kotlin — Back4app Android SDK
// The class gate in action: reads allowed, client writes blocked by CLP
val config = ParseObject("Config").apply { put("flag", true) }
config.saveInBackground { e ->
  if (e != null) {
    Log.d("CLP", "blocked: ${e.code}") // forbidden by class-level permissions
  }
}

Cómo trabajan juntos los permisos a nivel de clase y las ACLs

La escalera de granularidad: CLP vs. ACL vs. pointer permissions vs. campos protegidos

El idioma de diseño que se desprende: trazo grueso en el esquema, grano fino en las filas. Las clases con regla de acceso uniforme (config, catálogos, logs) solo necesitan el gate de la clase; las clases con datos por usuario agregan ACLs o pointer permissions debajo de él.

El mismo gate en otros motores

-- PostgreSQL: table-level privileges are CLPs by another name
GRANT SELECT ON films TO PUBLIC;
GRANT INSERT, UPDATE ON films TO role_editor;
REVOKE ALL ON launch_codes FROM PUBLIC;

Las bases de documentos lo reflejan con roles acotados a acciones a nivel de colección — un rol con find e insert sobre exactamente una colección. El concepto es universal; lo que cambia es la ergonomía: los grants de SQL y los documentos de roles se administran en código, mientras que las plataformas BaaS exponen la misma matriz como checkboxes en el dashboard.

Configuraciones recomendadas por tipo de contenido

Esa tabla es el checklist que la mayoría de los lanzamientos realmente necesita — nota la constante en la última columna y su regla hermana: la creación de clases desde el cliente apagada en producción, para que el esquema solo cambie a propósito.

Casos de uso comunes

• Congelar esquemas de producción. Add field apagado en todo; las clases dejan de aparecer y mutar por el tráfico de clientes.
• Datos de referencia de solo lectura. Catálogos y configuraciones legibles públicamente, escribibles solo por código del servidor — el patrón Config de arriba.
• Buzones de solo escritura. Clases de feedback y telemetría en las que los clientes pueden crear pero nunca leer — el gate inverso que el código de la capa de aplicación suele olvidar.
• Superficies de admin por rol. Update y delete reservados a un rol de admin mientras la app lee libremente.
• Defensa contra el dump clásico. El tristemente célebre one-liner — un curl con un app ID consultando una clase User abierta — muere en el gate de find cuando la clase exige autenticación.

¿Debería aplicarlo el gate de la clase o el código del servidor? Matriz de decisión

Se componen: el patrón endurecido para clases genuinamente sensibles bloquea las CLPs por completo y expone funciones del lado del servidor como la única puerta — el gate de la clase garantiza que nadie rodee el chokepoint.

Limitaciones y trade-offs

• La granularidad de clase es gruesa por definición. Todo lo que sea por fila pertenece a las ACLs y las pointer permissions; todo lo condicional pertenece a la validación del lado del servidor — las CLPs custodian, no razonan.
• Los defaults son permisivos para desarrollar. Las clases nuevas nacen abiertas para que los prototipos vuelen; la pasada previa al lanzamiento que aplica la tabla de arriba es una disciplina, no un automatismo.
• La master key lo ignora todo. Cada gate de este artículo es nulo allí donde viaja esa clave — por eso vive solo en el servidor, se usa por operación y jamás se envía al cliente.
• La superficie de enforcement debe ser completa. Las suscripciones en tiempo real y los endpoints especiales históricamente han tenido brechas — mantén la plataforma actualizada y prueba los gates desde un cliente real, no solo desde el dashboard.
• Los checkboxes también necesitan revisión. La seguridad declarativa solo es seguridad auditable si alguien la audita — la matriz de configuraciones pertenece a tu checklist de lanzamiento, no a la memoria tribal.

CLPs en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Los permisos a nivel de clase son su superficie de seguridad de esquema en versión visual: cada clase en el dashboard lleva la matriz de operaciones como checkboxes — público, exige autenticación, por rol — más pointer permissions y campos protegidos, aplicados del lado del servidor en cada solicitud por igual en SDKs, REST y GraphQL. Debajo están las ACLs por objeto; encima, los triggers de Cloud Code para las reglas que necesitan lógica. Las guías de seguridad recorren la pasada previa al lanzamiento completa — la matriz de configuraciones de este artículo, aplicada clic a clic.