Quella sottostante è una lista delle 10 vulnerabilità di sicurezza riscontrate nelle applicazioni web, e come Plone le risolve. L'intera trattazione per questa lista può essere trovato sul sito dell'Open Web Application Security Project.

Problema A1: Input Invalidato

Come lo gestisce Plone: Tutti gli input in Plone sono validati, e il framework si assicura che l'utente non sia mai in grado di inserire dati che non siano del tipo richiesto. Questo è probabilmente il motivo principale per cui i siti Plone - anche quando sviluppati e messi in produzione da persone che non sanno molto di sicurezza web - sono qualitativamente validi dal punto di vista della sicurezza.

Problema A2: Controllo degli Accessi non funzionante

Come lo gestisce Plone: Plone si basa sul ben-provato (7 anni in produzione), flessibile e granulare modello di sicurezza di Zope basato su ACL/Ruoli. Inoltre, Plone utilizza un innovativo approccio alla sicurezza basato su workflow, che significa che gli utenti finali non vedono o modificano mai i permessi di sicurezza - lavorano solo con impostazioni di sicurezza predefinite che sono state fornite loro dagli sviluppatori dell'applicazione. Questo rende la possibilità di commettere errori di sicurezza enormemente meno probabile che avvenga.

Problema A3: Gestione dell'Autenticazione e della Sessione non funzionanti

Come lo gestisce Plone: Plone autentica gli utenti nel suo database usando un hash SHA-1 per le loro password. Mediante il suo sistema di autenticazione modulare Plone può anche autenticare utenti usando sistemi di autenticazione diffusi come LDAP e SQL come pure qualsiasi altri sistema per cui sia disponibile un plugin (Gmail, OpenID, etc.). Dopo l'autenticazione, Plone crea una sessione usando un hash SHA-1 del secret memorizzato sul server e lo userid (HMAC-SHA-1). I secret possono essere rinnovati a intervalli regolare per aggiungere sicurezza extra dove sia necessario.

Nota: Vecchie versioni di Plone (prima di Plone 3) usano un metodo meno sicuro dove si utilizza un cookie di sessione contenente sia il loginname che la password dell'utente. E' molto consigliato per tali siti di forzare l'uso di crittazione HTTPS.

Problema A4: Cross Site Scripting

Come lo gestisce Plone: Plone dispone di un potente filtro sui contenuti caricati per essere certi che non possa essere caricato nel sistema codice potenzialmente malevolo. Tutto il contenuto inserito viene depurato da tag malevoli come <script>, <embed> e <object>, come pure vengono rimossi tutti i tag relativi a <form>, impedendo agli utenti di attivare qualsiasi forma di richiesta HTTP POST. Tutte le operazioni distruttive (come la cancellazione di contenuto) e di assegnazione di privilegi (ruoli, permessi) sono controllati per essere operati in richieste HTTP POST valide oltre ai controlli di sicurezza usuali. A livello infrastrutturale, il linguagio di template usato per generare le pagine in Plone quota tutto l'HTML di default, prevenendo in modo efficace il cross site scripting.

Problema A5: Buffer Overflow

Come lo gestisce Plone: vulnerabilità di Buffer overflow non sono state riportate per le versioni correnti di Python, è solitamente sono più comuni in sistemi basati su linguaggi che non hanno uno stretto controllo in tal senso, come lo C.

Problema A6: Problemi di Iniezione

Come li gestisce Plone: tali problemi sono comuni in sistemi che usano SQL come storage dei propri contenuti. Plone non usa SQL di default, e quando vengono predisposti database SQL con Plone, la comunicazione avviene sempre attraverso un connettore SQL standard che neutralizza automaticamente eventuali tentativi di iniezione.

Problema A7: Gestione degli Errori impropria

Come lo gestisce Plone: quando si verifica un errore Plone fornisce scarsa informazione all'interfaccia (nessuno stack trace o altro), tuttavia registra l'errore internamente. Tutto quello che vedrà l'utente finale è il numero di registrazione dell'errore che si è verificato, permettendo di identificarlo nei file di log se riportato all'amministratore del sito.

Problema A8: Storage Insicuro

Come lo gestisce Plone: tutti i metodi crittografici in uso nello stack di Plone sono stati esposti al pubblico scrutinio per lunghi anni, e non hanno vulnerabilità note.

Problema A9: Denial of Service dell'Applicazione

Come lo gestisce Plone: la configurazioe di rilascio tipica di un sito Plone utilizza un cache proxy come Squid, Varnish, Apache o IIS. Quando viene onfigurato in questa maniera, è molto difficile abbattere un sito Plone con attacchi DoS.

Nota: in versioni precedenti a Plone 2.1.4 e 2.5.1 esisteva un attacco Denial of Service potenziale identificato nela pagina di errore di Plone, che era inutilmente pesante. Questo è stato risolto come parte di un più ampio audit di sicurezza eseguito nello stesso periodo, e le versioni correnti di Plone non soffrono di questo problema.

Problema A10: Gestione della Configurazione Insicura

Come lo gestisce Plone: Plone di base dispone di default di sicurezza molto severi, e viene anche eseguito sul server con un utente non privilegiato. Gli utenti web non hanno accesso al file system. Per tali fattori, le più comuni vulnerabilità di configurazione della sicurezza in quest'area sono evitate.