Credenziali e dati seguono confini tecnici espliciti.
La sicurezza di SuperRankSEO dipende dal separare correttamente credenziali locali, OAuth Google, provider secret centrali, pacchetti di aggiornamento e stato operativo. Questa pagina descrive ciò che la documentazione tecnica supporta senza trasformarlo in claim legali non verificati.
Non tutte le chiavi appartengono allo stesso dominio
Una installazione WordPress, un account Google e un provider AI hanno trust boundary diversi. La documentazione 0.51.18 separa il Client dal Control proprio per evitare che configurazioni e secret centrali debbano essere distribuiti indiscriminatamente a ogni installazione.
Client / installazione
Il sito WordPress mantiene il proprio stato e le credenziali necessarie al rapporto con i servizi previsti dal prodotto.
Local installation boundary
Google OAuth
Search Console e GA4 vengono autorizzati dall’amministratore attraverso OAuth, non tramite password Google inserite nel plugin.
External account boundary
Provider centrali
Profili, modelli e secret centrali possono restare governati dal Control invece di essere replicati nel normale runtime client.
Control boundary
Un aggiornamento deve avere origine e integrità verificabili
La documentazione tecnica descrive un flusso di update dedicato, distinto dal repository pubblico standard, e include verifica SHA-256 dei pacchetti. Questo riduce il rischio di accettare un artefatto diverso da quello atteso, ma non sostituisce i normali controlli operativi sull’ambiente WordPress.
✓ l’origine dell’update resta parte del contratto del plugin
✓ il pacchetto può essere verificato rispetto all’hash previsto
✓ aggiornamento riuscito non equivale automaticamente a compatibilità applicativa: il sito va ancora verificato
Esempio di controlli tecnici
Update source
Endpoint previsto
Package checksum
SHA-256 verificabile
Install result
Separato dal runtime QA
Post-update
Verifica sito richiesta
Il dato mantiene la propria provenienza e dipendenza
Search Console, GA4, provider AI ed eventuali servizi di entity resolution hanno disponibilità e policy esterne al sito. La sicurezza architetturale consiste nel limitare il ruolo di ogni dipendenza e mantenere fallback quando il modulo lo supporta.
OAuth + API data
Il Client usa dati autorizzati senza trasformare le credenziali dell’account Google in password locali del plugin.
Central governance
Prompt, modelli e secret centrali possono essere gestiti dal Control e usati solo nei workflow che ne hanno bisogno.
Assisted resolution
Servizi esterni possono aiutare a risolvere entità; il grafo locale conserva fallback e criteri conservativi.
Continuity
Molte fondamenta Free continuano a funzionare localmente anche quando una dipendenza remota non è disponibile.
Quando un servizio esterno fallisce, il sistema deve mostrare il confine invece di nasconderlo
Rate limit, token scaduti, outage o errori provider non sono anomalie impossibili. La sicurezza operativa richiede che il Client distingua un errore remoto da uno stato locale valido e non trasformi un fallimento di trasporto in un risultato applicativo inventato.
Token o autorizzazione non validi
Il workflow deve richiedere una nuova autorizzazione o mostrare l’errore; non deve riutilizzare silenziosamente credenziali non valide.
Provider non raggiungibile
La funzione remota può degradare o essere ritentata secondo il proprio contratto; lo stato locale autorevole rimane separato.
Risposta remota incompleta
Una risposta parziale o ambigua deve restare tale: non viene promossa automaticamente a identità, stato indice o modifica applicata.
Questa è una pagina tecnica, non un DPA
La fonte prodotto non stabilisce da sola retention, data residency, subprocessors, basi giuridiche o responsabilità privacy contrattuali. Questi elementi richiedono documentazione operativa e legale separata prima di essere presentati come impegni.
GDPR / DPA
Non inferiamo conformità o impegni contrattuali dalla sola architettura software.
Retention
Non pubblichiamo tempi di conservazione senza una policy verificata per ciascun servizio e dataset.
Subprocessors / residency
Provider e localizzazione dei dati devono essere documentati da fonti operative correnti prima della pubblicazione.
Domande su credenziali e dati
Le risposte restano nel perimetro documentato dalla release 0.51.18.
Devo inserire la password Google in SuperRankSEO?
No. Search Console e GA4 vengono collegati tramite il flusso OAuth amministratore previsto dall’architettura.
Le chiavi dei provider AI vengono distribuite al plugin?
La documentazione architetturale supporta la governance centrale di provider, profili e secret invece della distribuzione ordinaria dei secret centrali al Client.
I dati restano sempre dentro WordPress?
No. Le funzioni locali restano nel Client, ma integrazioni Google e altri provider implicano servizi esterni. La pagina Trust descrive questi confini esplicitamente.
L’hash SHA-256 garantisce che un update sia sicuro in assoluto?
No. Verifica l’integrità dell’artefatto rispetto al valore atteso; compatibilità e comportamento del sito richiedono comunque QA applicativo.
Vedi come i confini diventano flussi
Architettura & Data Flow collega Client, Control, Google e provider al lifecycle operativo del prodotto. Per scenari di coesistenza con WordPress, WooCommerce, plugin SEO, cache e hosting, usa anche la matrice Compatibilità.