---
term: 'Permessi di classe (CLP) e sicurezza dello schema'
seoTitle: 'Permessi di classe (CLP): sicurezza dello schema'
headline: 'Che cosa sono i permessi di classe (CLP)?'
slug: permessi-di-classe-clp
category: database
shortDefinition: 'Un permesso di classe è una regola sullo schema di una classe che controlla quali utenti o ruoli possono eseguire ciascuna operazione su quella classe.'
relatedTerms:
  - access-control-lists-acl
  - row-level-security
  - role-based-access-control-rbac
  - data-layer-vs-application-layer-security
  - visual-database-management
contrastsWith:
  - access-control-lists-acl
aboutTerms:
  - 'Class-Level Permissions (CLPs)'
  - 'Schema Security'
faq:
  - question: 'Che cosa sono i permessi di classe?'
    answer: 'Regole allegate allo schema di una classe (tabella/collezione) che controllano quali utenti o ruoli possono eseguire ciascuna operazione – find, get, count, create, update, delete, add field – su qualsiasi oggetto di quella classe. Sono la barriera di accesso più grossolana e la prima a essere verificata: se la regola di classe nega un''operazione, nessun permesso per oggetto viene mai consultato.'
  - question: 'Qual è la differenza tra CLP e ACL?'
    answer: 'Portata e ordine. Un CLP risponde a "chi può toccare questa classe, in assoluto" – una regola per l''intera tabella. Un''ACL risponde a "chi può toccare questa riga precisa" – un dato portato da ciascun oggetto. Una richiesta deve superare entrambe le barriere: prima quella della classe, poi quella dell''oggetto, e ognuna può negare. Linee generali a livello di classe, grana fine a livello di oggetto.'
  - question: 'Che cos''è requiresAuthentication?'
    answer: 'L''impostazione intermedia fra pubblico e ruoli elencati: riserva un''operazione a qualsiasi utente connesso con una sessione valida, senza nominare utenti o ruoli precisi. È il valore predefinito giusto per quasi tutti i dati applicativi – le richieste anonime vengono rifiutate, mentre ogni utente autenticato supera la barriera della classe e passa ai controlli di ACL per oggetto.'
  - question: 'Che cosa sono le pointer permissions?'
    answer: 'Regole a livello di classe agganciate a un campo Pointer verso un utente sull''oggetto – per esempio "solo l''utente nel campo owner può leggere o scrivere". Agiscono come un''ACL virtuale: l''applicazione è per oggetto, ma la regola si dichiara una volta sola sullo schema invece di essere memorizzata su ogni riga. Si intersecano con le ACL vere; entrambe devono consentire l''azione.'
  - question: 'Che cosa sono i campi protetti (protected fields)?'
    answer: 'Regole a livello di campo sovrapposte alla barriera della classe: alcune colonne – un indirizzo e-mail, un punteggio interno – restano nascoste ad alcuni richiedenti mentre il resto dell''oggetto rimane leggibile. Trasformano la scala dei permessi in tre pioli su un unico schema: operazioni sull''intera classe, accesso per oggetto e visibilità per campo.'
  - question: 'Qual è l''equivalente SQL dei permessi di classe?'
    answer: 'I privilegi di tabella e di schema: GRANT SELECT, INSERT, UPDATE, DELETE ON una tabella a un ruolo, REVOKE per revocarli, più i diritti USAGE e CREATE a livello di schema. Il concetto si trasporta uno a uno – un GRANT a livello di tabella è un permesso di classe con un''altra sintassi – e i database documentali lo riproducono con ruoli limitati ad azioni a livello di collezione.'
  - question: 'I client devono poter aggiungere campi o creare classi in produzione?'
    answer: 'No – è il passo di irrobustimento su cui esiste consenso. La flessibilità dello schema è una comodità di sviluppo; in produzione conviene disattivare il permesso add field su ogni classe e spegnere del tutto la creazione di classi dal client, congelando lo schema nei confronti dei client. Le modifiche allo schema passano allora dalla dashboard o dal codice server, dove hanno il loro posto.'
  - question: 'I permessi di classe bastano a mettere in sicurezza un''app?'
    answer: 'Sono il primo strato, non l''intera difesa. Lo stack standard: i CLP filtrano le operazioni per classe, le ACL o le pointer permissions delimitano le righe, i campi protetti nascondono le colonne sensibili e i trigger lato server validano le scritture. E una regola sopra tutte: la master key – che aggira ogni barriera – non viene mai distribuita nel codice client.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Backend security guide'
    url: 'https://docs.parseplatform.org/parse-server/guide/#security'
  - name: 'PostgreSQL GRANT reference'
    url: 'https://www.postgresql.org/docs/current/sql-grant.html'
  - name: 'MongoDB collection-level access control'
    url: 'https://www.mongodb.com/docs/manual/core/collection-level-access-control/'
  - name: 'Back4app app security guidelines'
    url: 'https://www.back4app.com/docs/security/parse-security'
cta:
  title: 'Sicurezza dello schema con interruttori, non con politiche'
  text: 'Su Back4app i permessi di classe sono caselle da spuntare nella dashboard: blocca una classe, richiedi l''autenticazione, limita le operazioni ai ruoli, proteggi i campi – tutto applicato lato server a ogni richiesta, con le ACL per oggetto stratificate al di sotto.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-09'
translationKey: class-level-permissions-clp
---

**Un permesso di classe è una regola sullo schema di una classe che controlla quali utenti o ruoli possono eseguire ciascuna operazione su quella classe.** È la barriera più esterna della sicurezza dello strato dei dati: prima di qualsiasi controllo riga per riga, è la classe stessa a decidere se chi chiama possa fare find, create, update o delete qui – una regola, tutta la tabella, verificata per prima.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| Che cos'è | Regole di accesso per operazione sulla classe (tabella) stessa |
| vs. ACL | Il CLP presidia la classe; le ACL presidiano ogni riga – la richiesta deve superare entrambe |
| Le operazioni | Find, get, count, create, update, delete, add field – ciascuna impostata a parte |
| I valori predefiniti d'oro | Richiedere l'autenticazione, bloccare add field, non distribuire mai la master key |
| Il cugino SQL | `GRANT`/`REVOKE` su tabelle e schemi – stessa idea, altra sintassi |

## La barriera della classe, dichiarata e percepita

Un CLP è configurazione dello schema – qui nella forma del payload REST che blocca una classe `Config` in lettura pubblica e scrittura riservata al server:

```text
PUT /schemas/Config
{
  "classLevelPermissions": {
    "find":   { "*": true },              // chiunque può interrogare
    "get":    { "*": true },
    "create": {},                         // nessuno dal lato client
    "update": { "role:admin": true },     // solo gli admin
    "delete": {},
    "addField": {}                        // schema congelato
  }
}
```

Quello che i client sperimentano è la barriera che fa il suo lavoro – le letture passano, le scritture muoiono al confine della classe prima che un solo dato venga toccato:

**JavaScript:**

```javascript
// 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
// 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
}
```

**Swift:**

```swift
// 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
  }
}
```

**Kotlin:**

```kotlin
// 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
  }
}
```

## Come i permessi di classe e le ACL lavorano insieme

```mermaid
flowchart LR
  accTitle: Come si combinano i permessi di classe e le ACL
  accDescr: Ogni richiesta supera prima la barriera dei permessi di classe per la propria operazione; l'ACL per oggetto viene consultata solo se la classe la consente, e ciascuna delle due barriere può negare la richiesta.
  R["Richiesta:<br/>modificare l'oggetto X nella classe C"] --> G1{"Barriera di classe (CLP):<br/>chi chiama può<br/>modificare la classe C?"}
  G1 -- no --> D["Negato — 119"]
  G1 -- sì --> G2{"Barriera di oggetto (ACL):<br/>chi chiama può<br/>scrivere l'oggetto X?"}
  G2 -- no --> D2["Negato — oggetto nascosto"]
  G2 -- sì --> A["Consentito"]
```

## La scala della granularità: CLP vs. ACL vs. pointer permissions vs. campi protetti

| Meccanismo | Portata | Dichiarato dove | Verificato | Compito tipico |
| --- | --- | --- | --- | --- |
| Permesso di classe | Tutta la classe, per operazione | Schema | Per primo | "I client non scrivono mai su `Config`" |
| Pointer permission | Per oggetto, tramite una regola di schema | Schema (agganciata a un campo) | Per secondo | "Solo l'`owner` tocca le proprie righe" |
| ACL | Per oggetto | Su ciascuna riga, come dato | Per secondo | "Questa nota: solo il suo autore" |
| Campi protetti | Per colonna | Schema | Alla lettura | "Nascondere `email` agli altri utenti" |

L'idioma di progettazione che ne deriva: **le linee generali sullo schema, la grana fine sulle righe.** Le classi la cui regola di accesso è uniforme (configurazioni, cataloghi, log) hanno bisogno solo della barriera della classe; le classi con dati per utente aggiungono ACL o pointer permissions al di sotto.

## La stessa barriera in altri motori

```sql
-- PostgreSQL: i privilegi di tabella sono CLP con un altro nome
GRANT SELECT ON films TO PUBLIC;
GRANT INSERT, UPDATE ON films TO role_editor;
REVOKE ALL ON launch_codes FROM PUBLIC;
```

I database documentali lo riproducono con [ruoli limitati ad azioni a livello di collezione](https://www.mongodb.com/docs/manual/core/collection-level-access-control/) – un ruolo con find e insert su una sola collezione. Il concetto è universale; ciò che cambia è l'ergonomia: i GRANT SQL e i documenti di ruolo si amministrano nel codice, mentre le piattaforme BaaS espongono la stessa matrice come interruttori nella dashboard.

## Impostazioni consigliate per tipo di contenuto

| Tipo di contenuto | Find/Get | Create | Update/Delete | Add field |
| --- | --- | --- | --- | --- |
| Contenuti pubblici (catalogo, post) | Pubblico | Ruoli/server | Ruoli/server | Disattivato |
| Dati di proprietà dell'utente (note, ordini) | Autenticato + ACL | Autenticato | Delimitato da ACL | Disattivato |
| Configurazioni e flag | Pubblico o autenticato | Nessuno (solo server) | Ruolo admin | Disattivato |
| Log e analitiche | Nessuno (solo server) | Autenticato (sola scrittura) | Nessuno | Disattivato |
| Dati riservati agli admin | Ruolo admin | Ruolo admin | Ruolo admin | Disattivato |

Quella tabella è la checklist di cui ha davvero bisogno la maggior parte dei lanci – vale la pena notare la costante nell'ultima colonna e la sua regola sorella: creazione di classi dal client disattivata in produzione, così che lo schema cambi solo di proposito.

## Casi d'uso tipici

- **Congelare gli schemi di produzione.** Add field disattivato dappertutto; le classi smettono di comparire e di mutare per effetto del traffico dei client.
- **Dati di riferimento in sola lettura.** Cataloghi e impostazioni leggibili pubblicamente, scrivibili solo dal codice server – lo schema `Config` qui sopra.
- **Caselle in sola scrittura.** Classi di feedback e telemetria in cui i client possono creare ma non leggere mai – la barriera inversa che il codice dello strato applicativo dimentica spesso.
- **Superfici di amministrazione a livelli di ruolo.** Update e delete riservati a un ruolo admin, mentre l'app legge liberamente.
- **Difesa dal dump classico.** La famigerata riga di comando – un curl con un app ID che interroga una classe `User` aperta – muore alla barriera find appena la classe richiede l'autenticazione.

## Barriera della classe o codice server? Matrice decisionale

| Applicare con i CLP (+ ACL) quando… | Passare dal codice server quando… |
| --- | --- |
| La regola è "chi può fare che cosa, dove" | La regola richiede logica di business ("solo prima che l'ordine venga spedito") |
| È uniforme per classe o per proprietario | Riguarda più oggetti o più classi |
| Serve che valga su ogni percorso, compresi i client nuovi | Serve un unico punto di passaggio verificato per un flusso sensibile |
| Per la revisione il dichiarativo batte l'imperativo | Validazione, arricchimento o effetti collaterali viaggiano insieme |
| L'interruttore nella dashboard è tutta la specifica | La specifica è un paragrafo di condizioni |

I due approcci si compongono: lo schema irrobustito per le classi davvero sensibili blocca interamente i CLP ed espone funzioni lato server come unica porta d'ingresso – la barriera della classe garantisce che nessuno aggiri il punto di passaggio.

## Limiti e trade-off

- **La granularità di classe è grossolana per definizione.** Tutto ciò che è per riga appartiene alle ACL e alle pointer permissions; tutto ciò che è condizionale appartiene alla validazione lato server – i CLP presidiano, non ragionano.
- **I valori predefiniti sono permissivi per lo sviluppo.** Le classi nuove nascono aperte perché i prototipi corrano; la passata di prelancio che applica la tabella qui sopra è una disciplina, non un automatismo.
- **La master key ignora tutto.** Ogni barriera di questo articolo cade dove quella chiave circola – ed è per questo che vive solo lato server, usata operazione per operazione, mai distribuita.
- **La superficie di applicazione deve essere completa.** Le sottoscrizioni in tempo reale e gli endpoint speciali hanno avuto storicamente dei buchi di applicazione – conviene tenere la piattaforma aggiornata e provare le barriere da un client reale, non solo dalla dashboard.
- **Anche gli interruttori vanno rivisti.** La sicurezza dichiarativa è sicurezza verificabile solo se qualcuno la verifica – la matrice delle impostazioni appartiene alla checklist di lancio, non alla memoria collettiva.

## I CLP su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. I permessi di classe sono la sua superficie di sicurezza dello schema resa visiva: ogni classe nella dashboard porta la matrice delle operazioni come caselle da spuntare – pubblico, autenticazione richiesta, per ruolo – più le pointer permissions e i campi protetti, [applicati lato server a ogni richiesta](https://docs.parseplatform.org/parse-server/guide/#security) attraverso gli SDK, REST e GraphQL allo stesso modo. Al di sotto stanno le ACL per oggetto; al di sopra, i trigger di Cloud Code per le regole che hanno bisogno di logica. Le [linee guida di sicurezza](https://www.back4app.com/docs/security/parse-security) ripercorrono l'intera passata di prelancio – la matrice delle impostazioni di questo articolo, applicata clic per clic.