Questa pagina descrive il modello di sicurezza di WebBlocks CMS e i passaggi che un operatore o l'agenzia dovrebbe provvedere a gestirlo in sicurezza per i siti dei clienti. Per come segnalare a vulnerabilità, vedere SECURITY.md — non aprire al pubblico problemi per i rapporti sulla sicurezza.

Questi sono i controlli più importanti per un'installazione di produzione:

• Serve solo public/ come root web. La root dell'applicazione contiene .env, .git, .github, storage/, vendor/ e il codice sorgente che deve non essere mai raggiungibile dal web. Punta la root del tuo documento Nginx/Apache su public/ e confermare che https://your-site/.git/config e https://your-site/.env restituiscono entrambi 404. Una directory .git esposta perde l'intera fonte e tutti i segreti impegnati.
• Preferisci un artefatto di rilascio rispetto a un clone git non elaborato in produzione. Rilascio i pacchetti escludono .git, .github, project/ e altri file non runtime (vedi regolamento .gitattributes export-ignore). Se distribuisci un clone, disabilitalo premere sull'installazione (git remote set-url --push origin DISABLED).
• Set APP_DEBUG=false e un forte APP_KEY in produzione. Modalità di debug perde tracce di stack, valori di ambiente e percorsi interni.
• Utilizza HTTPS e imposta SESSION_SECURE_COOKIE=true quando pubblichi su TLS.
• Autorizzazioni file: l'utente web/PHP deve leggere/scrivere su storage/ e il Root del disco backups (storage/app/backups predefinito). non utilizzare 777; concedere invece la proprietà o l'accesso al gruppo.
• Mantieni i segreti in .env. .env, .env.* (eccetto .env.example) e auth.json sono ignorati da git. I token API CMS e le password di posta non lo sono mai scritto nel repository.

• L'autenticazione CMS è nativa Laravel (nessun requisito Breeze/Jetstream/Fortify). Amministratori accedi a /webadmin/login; le password hanno l'hash bcrypt.
• Accesso al gate con tre ruoli di installazione: super_admin (a livello di installazione), site_admin (siti assegnati) e editor (bozza di contenuto all'interno dei siti assegnati). Intersito le azioni (sposta/duplica, Shared Slots) impongono l'accesso sia all'origine che alla destinazione siti. Vedere Utenti e autorizzazioni.
• L'albero di amministrazione /webadmin è protetto dal CMS web + autenticazione + accesso amministratore pila del middleware. I percorsi pubblici non eseguono mai il rendering del contenuto in bozza; bozza/anteprima l'accesso richiede un amministratore autenticato o un token attendibile con content.read.
• Le richieste di accesso e di reimpostazione della password hanno una frequenza limitata. Gli accessi non riusciti sono limitato per e-mail+IP (5 tentativi predefiniti, quindi un breve blocco che a l'accesso riuscito viene cancellato; sintonizzarsi con WEBBLOCKS_CMS_MAX_LOGIN_ATTEMPTS e WEBBLOCKS_CMS_LOGIN_DECAY_SECONDS). Un backstop per IP limita inoltre il endpoint di accesso, password dimenticata e reimpostazione password contro inondazioni e tentativi di rotazione della posta elettronica.

Internal Content API (/webadmin/api) è destinato agli operatori affidabili/strumenti AI.

• I token personali vengono creati da qualsiasi utente CMS attivo da Profile → Personale Token API; I token di sistema a livello di installazione vengono creati da un super_admin da Sistema → Token API. Entrambi sono memorizzati come hash e mostrati in chiaro testo solo una volta.
• Ogni token porta funzionalità esplicite (lettura, pubblicazione, media, plugin ciclo di vita, commercio,…). Le funzionalità avanzate/distruttive sono opt-in separati; le normali funzionalità di creazione della pagina sono l'impostazione predefinita.
• I token possono essere revocati (mantenendo la riga di controllo) o eliminati. Un token il registro delle attività registra l'ora, il metodo/percorso, il percorso, il risultato della capacità, l'IP e a riepilogo dello user-agent, ma non richiedere mai corpi, stringhe di query, risposte o valori simbolici.
• Tratta i token API come segreti. Applicali alle capacità minime di uno strumento esigenze e ruotarli se esposti.
• I token API personali intersecano continuamente funzionalità e siti selezionati con il ruolo attivo, lo stato attivo, le assegnazioni del sito e la pagina del proprietario autorità del flusso di lavoro. Le operazioni a livello di installazione rimangono solo token di sistema.
• I token API personali possono essere limitati a indirizzi IPv4/IPv6 esatti o CIDR reti e portano un tetto massimo di richieste al minuto specifico per token. Questi controlli vengono applicati in aggiunta all'accesso degli utenti live, del sito, del flusso di lavoro e delle funzionalità.
• Sia i percorsi canonici /webadmin/api che quelli legacy /admin-api i percorsi di compatibilità condividono il limitatore di velocità Internal Content API.

Quando è presente un proxy inverso o una CDN, configura Laravel per considerare attendibile solo il file indirizzi proxy effettivi e verificare l'IP del client risolto prima di abilitare un lista consentita. Non accettare mai intestazioni inoltrate falsificabili direttamente da Internet.

Vedi Token API personali e Internal Content API.

Gli aggiornamenti di sistema in-app sostituiscono il codice del pacchetto CMS in vendor/fklavyenet/webblocks-cms sul sito live. Perché un aggiornamento viene eseguito new codice, l'integrità del pacchetto scaricato è un'esecuzione del codice remoto confine. WebBlocks CMS mitiga questo problema come segue:

• Checksum SHA-256 obbligatorio. Il programma di aggiornamento scarica lo ZIP della versione, quindi verifica hash_file('sha256', …) rispetto allo checksum_sha256 fornito dal rilasciare i metadati utilizzando uno hash_equals timing-safe. Se manca il checksum or non corrisponde, l'aggiornamento è refused — non torna a applicando un pacchetto non verificato.
• Servizio di aggiornamento canonico. I metadati e i download dell'aggiornamento provengono da publisher.webblocksui.com. Poiché il checksum viene consegnato insieme al file scaricato dallo stesso servizio, il checksum protegge da file corrotti o artifacts manomesso, ma non contro un servizio di aggiornamento completamente compromesso.
• Le installazioni sono consumatori, non editori. I siti installati recuperano gli aggiornamenti ma non deve essere inviato al repository upstream. La pubblicazione viene eseguita solo dal file controllo di manutenzione con WEBBLOCKS_PUBLISHER_TOKEN.

Per una difesa approfondita contro un servizio di aggiornamento compromesso, dove il checksum viaggia insieme all'artefatto: le versioni possono essere firmate crittograficamente. L'editore firma il checksum del rilascio con una chiave segreta Ed25519 e installa verificare la firma rispetto a una chiave pubblica bloccata (sodium_crypto_sign), quindi un l'installazione rifiuta qualsiasi versione non firmata dalla chiave reale.

Per abilitarlo:

1. Genera una coppia di chiavi una volta, sulla macchina di manutenzione/pubblicazione: php artisan webblocks:updates:keygen.
2. Mantieni privato il WEBBLOCKS_PUBLISHER_SIGNING_KEY stampato (segreto) - impostalo solo dove pubblichi pubblicazioni. Non eseguirne mai il commit o l'impostazione su un install.
3. Inserisci la chiave pubblica stampata in modo che le installazioni verifichino le versioni firmate: imposta WEBBLOCKS_UPDATE_PUBLIC_KEY, oppure impostare ReleaseDefaults::UPDATE_PUBLIC_KEY in questo modo la chiave viene fornita nel codice CMS (consigliato: una chiave con codice aggiunto non può essere scambiato tramite uno .env compromesso).
4. Pubblica come al solito; l'editore firma automaticamente ogni pubblicazione.

L'implementazione è sicura: anche se non viene bloccata alcuna chiave pubblica, la verifica della firma non lo è applicato (la verifica del checksum si applica ancora). Una volta bloccata una chiave pubblica e le installazioni ricevono quel codice, ogni versione futura deve contenere un Ed25519 valido firma sul checksum oppure l'aggiornamento viene rifiutato.

• Moduli pubblici condividono una pipeline di protezione locale: prova firmata associata al modulo, honeypot generati, tempistica, punteggio di contenuto/ripetizione, mittente e fonte con chiave contatori, pressione di rete /24 o /64 e impronte digitali apprese a livello locale. Non fa alcuna richiesta esterna. I contatori di protezione utilizzano hash con chiave; metriche giornaliere contenere solo decisioni aggregate. Vedere Invio pubblico Protezione.
• Moduli di contatto Store ha ottenuto gli invii per la revisione. Quarantena e soppressione dello spam notifica pur rimanendo separato dalla cronologia di consegna delle notifiche. Vedi Moduli di contatto e messaggi.
• Commenti predefinito su pending; una decisione relativa allo spam viene conservata come spam e mai più appare pubblicamente senza moderazione.
• Trusted HTML è limitato al markup del layout adiacente al wrapper e non deve essere utilizzato per iniettare script; preferiscono i contratti a blocchi nativi, che gli Internal L'API dei contenuti convalida prima la bozza.
• I caricamenti multimediali sono limitati a una lista consentita di immagini, video e documenti type (sniffato dal contenuto, non attendibile dall'estensione). I caricamenti SVG sono disabilitati per impostazione predefinita, perché un SVG può contenere script in linea e da cui vengono serviti i contenuti multimediali la stessa origine dell'amministratore. Abilitalo solo su installazioni in cui ogni account che può caricare contenuti multimediali è attendibile, tramite WEBBLOCKS_CMS_ALLOW_SVG_UPLOADS=true. La stessa lista consentita regola i recuperi multimediali remoti lato server.
• Il recupero dei media remoti convalida ogni destinazione di reindirizzamento e blocca l'HTTP connessione all'indirizzo IP pubblico che ha superato la validazione. Questo chiude il Gara di ricerca/connessione DNS utilizzata dagli attacchi di riassociazione DNS. Recupero remoto non viene chiuso quando PHP il blocco dell'indirizzo cURL non è disponibile.
• Gli iframe dell'applicazione incorporata gestita sono sandbox di origine opaca. Loro le risposte alle voci applicano CSP restrittivo e intestazioni di riferimento. CSP nomina il l'origine del sito registrato corrente in modo esplicito in modo che i documenti di origine opaca possano essere caricati gli script, gli stili, i contenuti multimediali e l'URL <base> dello stesso sito senza concedere il iframe accesso della stessa origine ai cookie CMS, all'archiviazione, alla pagina principale o richieste pannello autenticate.
• I pacchetti completi di applicazioni integrate rimangono isolati. Immutabile, i file del pacchetto con versione vengono serviti tramite un percorso pubblico riservato solo all'applicazione con CORS anonimo e intestazioni di risorse multiorigine, che consentono l'origine opaca giochi per caricare immagini, audio, caratteri, JSON e file locali senza concedere allow-same-origin. L'installazione ZIP rifiuta l'attraversamento, i percorsi duplicati, file eseguibili del server e violazioni di conteggio limitato o di dimensioni espanse.

• I controlli degli aggiornamenti possono inviare dati di telemetria sull'adozione che preservano la privacy all'editore: solo product_key, installed_version, channel, un casuale persistente localmente installation_id e telemetry_schema_version. Nessun dominio, URL, amministratore e-mail, percorsi, dettagli del database, conteggi degli utenti, token o env/config arbitrari vengono inviati i valori Imposta WEBBLOCKS_TELEMETRY=false per disattivare; controlli dei metadati continuare senza un ID di installazione.
• I rapporti sui visitatori conservano i record delle visualizzazioni di pagina con percorso, ora e referrer normalizzato host, valori UTM, categoria del dispositivo e classificazione del bot. Basato sul consenso completo il tracciamento può anche conservare una chiave di sessione e un IP HMAC; questi sono pseudonimi identificatori, non una garanzia di anonimato. Nuovi grafici e modalità di dettaglio della pagina non introdurre identificatori aggiuntivi o script di tracciamento pubblici. Programmato la conservazione sostituisce i dettagli scaduti con i conteggi giornalieri del sito/locale e successivi scade quei conteggi. Vedere Operazioni.

Segnalare privatamente tramite GitHub Security Advisories o il contatto del manutentore in SICUREZZA.md. Il nostro obiettivo è riconoscere le segnalazioni all'interno di 5 aziende giorni e coordineremo con te una tempistica di divulgazione.

CMS convalidano il candidato in un processo PHP separato prima dell'attivazione in runtime normale. Origine non valida, errori del provider/percorso, uscite anticipate e timeout lo rifiutano; un aggiornamento rifiutato mantiene il pacchetto funzionante. Gli errori di configurazione del database mantengono il plug-in disabilitato e ne preservano i dati. Gli errori dell'origine runtime o del percorso mettono in quarantena il plug-in interessato e rimuovono i percorsi parzialmente registrati.

La schermata /webadmin/plugin-recovery e il caricamento del login senza la sorgente del plugin installata. CMS 1.94.2 applica l'accesso amministrativo con account attivo e l'autorizzazione Super admin, incluse le sessioni esistenti. Il ripristino può disabilitare il plug-in in errore o ripristinare il pacchetto precedente conservato solo quando non è stata eseguita alcuna migrazione del database; il ripristino ripete la convalida di avvio e ripubblica le risorse precedenti. I normali controlli di accesso e la protezione CSRF rimangono in vigore. Ciò protegge il percorso di ripristino del plug-in gestito, non i provider host arbitrari o l'isolamento dell'eseguibile PHP. Vedi Sistema plugin.

Gli aggiornamenti di installazione richiedono un token di sistema a livello di installazione di proprietà di un utente attivo con accesso al sistema. system-updates.read e system-updates.run sono opt-in separati; né i token personali né i token con ambito sito possono utilizzarli. L'esecuzione richiede l'approvazione esplicita della versione installata, della versione di destinazione e del checksum, con una ricevuta di idempotenza durevole per risposte incerte. Vedi Aggiornamenti.