Sicurezza del livello dati vs. del livello applicativo

La sicurezza del livello applicativo è una guardia nel codice; quella del livello dati è una guardia sui dati stessi: servono entrambe. Non sono sinonimi, anche se perfino alcuni glossari ben posizionati li confondono: il livello applicativo mette in sicurezza il comportamento (autenticazione, validazione, regole di business), il livello dati mette in sicurezza l’informazione archiviata (policy, ACL, crittografia) contro ogni percorso di accesso – compresi quelli che il codice non vede mai.

Punti chiave

Il bug che riassume il dibattito

Il controllo nel livello applicativo è corretto – finché qualcuno non dimentica di ripeterlo:

// Endpoint uno: il controllo di proprietà, presente e corretto
app.get('/contracts/:id', async (req, res) => {
  const contract = await db.contracts.findById(req.params.id);
  if (contract.ownerId !== req.user.id) return res.status(403).end();
  res.json(contract);
});

// Endpoint due, tre sprint più tardi, in un altro file:
app.get('/contracts/:id/export', async (req, res) => {
  const contract = await db.contracts.findById(req.params.id);
  res.send(toPdf(contract));   // ← nessuno ha riscritto il controllo. IDOR in produzione.
});

L’applicazione delle regole nel livello dati inverte il guasto: la regola viaggia con la riga, quindi il controllo dimenticato non ha più nulla da dimenticare –

// JavaScript / Node.js — Back4app JS SDK
// Data-layer enforcement: the rule travels with the row, not the code path
const doc = await new Parse.Query('Contract').get(contractId); // someone else's row
doc.set('total', 0);
try {
  await doc.save(); // rejected by the object's ACL — server-side, every path
} catch (e) {
  console.log(e.code); // 101: object not found for update
}

// Flutter / Dart — Back4app Flutter SDK
// Data-layer enforcement: the rule travels with the row, not the code path
final doc = ParseObject('Contract')..objectId = contractId;
doc.set('total', 0);
final response = await doc.save();
if (!response.success) {
  print(response.error?.code); // rejected by the object's ACL, server-side
}

// iOS / Swift — Back4app Swift SDK
// Data-layer enforcement: the rule travels with the row, not the code path
var doc = Contract(objectId: contractId)
doc.total = 0
doc.save { result in
  if case .failure(let error) = result {
    print(error.code ?? .unknownError) // rejected by the object's ACL
  }
}

// Android / Kotlin — Back4app Android SDK
// Data-layer enforcement: the rule travels with the row, not the code path
val doc = ParseObject.createWithoutData("Contract", contractId)
doc.put("total", 0)
doc.saveInBackground { e ->
  if (e != null) Log.d("Security", "blocked by ACL: ${e.code}") // server-side
}

Difesa in profondità: stratificare la sicurezza attorno ai dati archiviati

La freccia tratteggiata è l’argomento: tutto ciò che salta l’applicazione arriva comunque al livello dati – ed è per questo che regole che vivono solo nei controller proteggono una sola porta di una stanza che ne ha molte. È la difesa in profondità applicata all’archiviazione: barriere sovrapposte che cedono in modo diverso.

Livello dati vs. livello applicativo: chi fa cosa

Due righe portano tutto il dibattito. Le regole di workflow – catene di approvazione, macchine a stati, limiti – hanno bisogno di un contesto che solo il codice possiede; forzarle in predicati di riga produce una zuppa di policy impossibile da mantenere. Le regole strutturali – proprietà, appartenenza a un tenant, visibilità – sono esattamente ciò che le policy per riga e le ACL per oggetto fanno rispettare senza disciplina endpoint per endpoint. Ogni regola va collocata dove la sua modalità di guasto resta sopravvivibile.

IDOR: il dibattito sui livelli, con un elenco di CVE

Il guasto di controllo degli accessi in testa alla classifica – e n. 1 nell’elenco specifico per le API – è precisamente il controllo dimenticato nel codice qui sopra: utenti autenticati che recuperano oggetti per ID senza alcuna autorizzazione per oggetto. Le pagine di sicurezza catalogano la vulnerabilità; quelle di architettura catalogano i livelli; il nesso fra le due è la parte utile: l’IDOR è l’aspetto che prende su larga scala una sicurezza applicata solo nell’app, e le policy del livello dati ne sono la correzione strutturale, perché il controllo mancato si risolve in un rifiuto invece che in una porta aperta.

Come il BaaS sposta il confine

Le piattaforme di Backend as a Service rendono architetturale la tesi di questo articolo: con i client che parlano (quasi) direttamente con il servizio dati, non esiste più un livello di controller scritti a mano a reggere i controlli – quindi l’autorizzazione deve vivere in costrutti del livello dati. Le ACL per oggetto portano la proprietà, i permessi di classe regolano le operazioni per schema, e la piattaforma fa rispettare entrambi a ogni richiesta, da qualunque superficie arrivi. Il livello applicativo non svanisce; si sposta in funzioni lato server che portano la validazione e le regole di workflow – la separazione in due livelli, imposta dalla progettazione invece che dalla disciplina.

Casi d’uso tipici

• SaaS multi-tenant. L’appartenenza a un tenant è la regola strutturale canonica – applicata nel livello dati, testata in modo avversariale, mai affidata a clausole WHERE.
• Record di proprietà degli utenti. Messaggi, documenti, ordini: la proprietà è portata dalla riga tramite le ACL; il codice dell’app resta leggibile, i dati restano sigillati.
• Accesso analitico e BI. Il percorso di aggiramento reso sicuro: chi fa analisi interroga direttamente le repliche e vede solo ciò che le regole del livello dati consentono.
• Prove di conformità. I revisori preferiscono controlli dimostrabili al livello dei dati ai rimandi al codice applicativo.
• Workflow di approvazione. Il controesempio: le regole di business che dipendono dallo stato vivono nella logica applicativa – con le regole strutturali che tengono comunque al di sotto.

Dove va ogni regola? Matrice decisionale

E la regola permanente sopra le due colonne: i livelli si combinano in AND, non in OR – conviene tenere i controlli del livello applicativo per chiarezza e UX, e lasciare che il livello dati renda sopravvivibile la loro assenza.

Limiti e trade-off

• Tutto nel codice applicativo: logica duplicata da un endpoint all’altro, deriva fra microservizi e ogni percorso di aggiramento senza protezione – la fabbrica di IDOR.
• Tutto nei dati: regole invisibili che disorientano chi fa il debug, costi di valutazione per riga, sottigliezze di contesto con il pooling e logica di business contorta in predicati.
• I due insieme costano coordinamento. Due posti da aggiornare quando una regola cambia; conviene tenere le regole strutturali poche, stabili e documentate.
• La collocazione della crittografia è un bivio reale. Lato database è trasparente e interrogabile; lato applicazione separa le chiavi ma complica le query – si decide campo per campo, minaccia per minaccia.
• Il confine stesso va verificato. Chi detiene credenziali di aggiramento – ruoli di amministrazione, master key – sta fuori da ogni cerchio; quell’elenco è il perimetro effettivo.

I due livelli 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. Consegna la conclusione di questo articolo come architettura predefinita: il livello dati porta le regole strutturali – ACL per oggetto, permessi di classe, campi protetti, applicati lato server a ogni richiesta – mentre i trigger di Cloud Code portano la parte del livello applicativo: validazione, arricchimento e controlli di workflow che girano prima che una scrittura vada a segno. Il bug del filtro dimenticato non ha alcun percorso per passare, e le regole di business mantengono un posto dove vivere.