Anti-quishing lato emissione. Residenza dati lato storage.
Ogni link Pro passa attraverso una pipeline anti-quishing a sette livelli al momento dell'emissione, ad ogni cambio di destinazione e con cadenza periodica. Il log di scansione è solo paese + classe dispositivo, senza IP, user agent, cookie né profilo comportamentale da esporre. D1 in singola regione è disponibile su Agency e Enterprise personalizzato.
Dati che raccogliamo
Ogni byte che finisce sui nostri server rientra in uno di quattro bucket:
Dati account
Email, livello del piano, stato del piano, ID cliente + abbonamento Stripe, nome team opzionale + etichetta workspace. Tutto qui. Nessun telefono, nessun indirizzo (l'indirizzo di fatturazione resta su Stripe), nessun profilo comportamentale.
Dati codici
L'URL di destinazione, uno shortcode Base58 a 7 caratteri, un'etichetta + tag da te impostati, design QR opzionale (colori / logo / cornice), gate password opzionale, pianificazione opzionale. Di tua proprietà; esportabile come CSV in qualsiasi momento.
Dati scansioni
Bucket giornaliero UTC + paese (da CF-IPCountry) + classe dispositivo (mobile / tablet / desktop / unknown). Lo User-Agent grezzo viene scartato immediatamente dopo la classificazione. L'IP non entra mai nel database. Cachati in KV per il percorso di redirect, aggregati in D1 via ctx.waitUntil. Gli aggregati per paese sotto 5 scansioni vengono raggruppati in «Other» per prevenire la re-identificazione.
Metadati audit / fatturazione
Log append-only delle mutazioni (chi ha fatto cosa, quando, in quale scope), retention 180 giorni. Eventi webhook Stripe deduplicati per idempotenza, nessun PII cliente oltre l'ID cliente Stripe. Log richieste GDPR (esportazione / eliminazione / ripristino), conservato dopo l'eliminazione dell'account per dimostrare il rispetto puntuale di ogni richiesta.
Per lo schema completo, vedi docs/SCHEMA.md nel nostro repo sorgente; ogni colonna è documentata con una policy di retention.
Dove vivono i dati
| Superficie | Provider | Regione | Opzione singola regione? |
|---|---|---|---|
| Dashboard + API | Cloudflare Pages Functions | Edge globale (PoP più vicino) | Sì, solo Agency+ |
| Record codici (D1) | Cloudflare D1 (SQLite) | Regione primaria assegnata al provisioning (oggi: ENAM) | Sì, shard per tenant Agency+ |
| Redirect hot path (KV) | Cloudflare Workers KV | Replicato sull'edge globale per <50ms p99 | Non disponibile (la replica è il prodotto) |
| Backup cifrati | Cloudflare R2 | Regione primaria assegnata alla creazione del bucket | Sì, bucket in giurisdizione EU / APAC su richiesta |
| Pagamenti | Stripe | US, gestione PII regionale tramite la propria residenza Stripe | Tramite contratto Stripe |
| Email transazionale | ZeptoMail (Zoho) | IN (regione EU Zoho disponibile su richiesta) | Sì, regione EU Zoho |
Cosa attraversa un confine, esattamente
- Le scansioni non attraversano mai un confine in modo lossy. Una scansione da Lisbona colpisce il PoP Cloudflare di Lisbona, il worker scrive giorno/paese/dispositivo in KV sull'edge e aggrega in modo asincrono in D1 nella sua regione primaria. L'IP originale dello scanner vive nello stato effimero della richiesta Cloudflare per la durata della richiesta HTTP e non viene mai persistito nel nostro database.
- Le richieste alla dashboard terminano al PoP Cloudflare più vicino e chiamano D1 sulla rete privata Cloudflare. Le nostre Pages Functions leggono/scrivono D1 nella sua regione assegnata; il PoP edge serve il bundle HTML + JS dalla cache globale degli asset statici.
- I webhook Stripe attraversano il confine una volta, Stripe (US) fa POST al nostro endpoint Cloudflare Pages, che verifica l'HMAC, scrive una riga minimale (event_id, type) per l'idempotenza e smista gli eventi downstream.
- L'email transazionale (Zepto) attraversa il confine una volta per invio, il nostro worker consegna un template renderizzato all'API Zepto; Zepto consegna al mailserver del destinatario. Il contenuto è link di invito, notifiche del ciclo di vita di fatturazione e avvisi di limite scansioni, nessun dato di scansione cliente.
Pipeline anti-quishing
Il QR phishing è cresciuto del 146% nel Q1 2026. Il vendor standard di short link reagisce solo dopo una segnalazione del cliente. Noi controlliamo ogni link al momento dell'emissione, ogni volta che la destinazione viene modificata sul nostro lato, e con cadenza periodica, perché un cliente può reindirizzare il proprio URL sul proprio server senza mai chiamare la nostra API. La stessa pipeline di threat intelligence che alimenta il nostro scanner pubblico su check.qr.abundera.ai viene eseguita su ogni link che emettiamo.
Sette livelli di rilevamento, ciascuno con una domanda di brevetto US in corso. Ogni livello alimenta un verdetto unificato; un segnale su qualsiasi livello può bloccare una creazione, rifiutare un cambio di destinazione o sospendere un link già attivo.
| Livello | Cosa rileva | Quando viene eseguito |
|---|---|---|
| Mutabilità della catena di redirect | Quante parti indipendenti controllano il percorso tra il nostro short link e la pagina finale. Una catena a due hop attraverso il redirector di terzi è una classe di rischio diversa da una destinazione diretta. | Creazione, cambio destinazione, ricontrollo periodico |
| Analisi payload multimodale | WiFi, contatti, telefonia, mail, calendario, geolocalizzazione, criptovalute, intent Android e payload inline-data ricevono ciascuno un analizzatore specifico per tipo. Gli schemi hard-blocked vengono rifiutati al submit. | Creazione, cambio destinazione |
| Cloaking crawler-vs-browser | Pagine che servono contenuto pulito agli scanner e phishing agli utenti reali. Rilevato tramite fetch paralleli con varianza controllata delle impronte e un punteggio di divergenza. | Creazione, ricontrollo periodico |
| Mutabilità del server di destinazione | Domini registrati di recente, certificati nuovissimi, TLD ad alta rotazione, HSTS mancante e degradazione dello schema di trasporto. Indipendente dalla catena di redirect; una catena statica a un hop verso un cert di sei giorni su un TLD sospetto viene comunque segnalata. | Creazione, cambio destinazione, ricontrollo periodico |
| Provenienza dell'istanza fisica | Ledger di hash crowd-sourced indicizzato dal payload decodificato. Un singolo QR scansionato in molte regioni disparate in breve tempo emerge come candidato attacco-adesivo. Ogni link che emettiamo riceve una voce di provenienza pulita alla creazione, così gli attacchi overlay contro codici Pro legittimi vengono intercettati. | Continuo |
| Divergenza visiva del brand | Se un codice porta un logo di brand il cui insieme di domini canonici non include la destinazione decodificata, il codice è brand-divergente. Si applica a ogni codice Pro che usa la funzione logo centrale; un phisher non può distribuire un codice con logo Chase che punta a un dominio non-Chase. | Creazione, cambio logo, cambio destinazione |
| Topologia sensore / venue | Per i codici legati a un venue (parchimetri, check-in hotel, menu ristorante, mostre museali), il contesto RF ambientale del dispositivo di scansione viene verificato rispetto alla topologia registrata per quel venue. Un mismatch restituisce un'anomalia di contesto sensore anche alla primissima scansione di un adesivo fraudolento. Livello Enterprise; l'operatore del venue registra la topologia attesa alla creazione del codice. | Ogni scansione |
Il problema del cambio lato cliente
L'URL di destinazione di un link Pro vive sul server del cliente, non sul nostro. Il cliente può reindirizzare example.com/promo da una promo reale a una pagina di phishing senza mai chiamare l'API Abundera. Trattiamo questo come il vettore di abuso principale, non un caso limite. I ricontrolli periodici delle destinazioni attive girano su un ciclo programmato, e il nostro livello di rilevamento del cloaking prende di mira specificamente le pagine che cambiano dopo il submit. Quando una destinazione inizia a fallire i controlli dopo la creazione, il link viene messo automaticamente in pausa, il proprietario riceve un'email con il verdetto specifico e l'evento viene registrato nell'audit trail.
Falsi positivi e ricorsi
La threat intel a volte sbaglia. Un brand legittimo su un cert appena emesso, una promo reale la cui pagina è cambiata legittimamente, un dominio migrato. Ogni blocco e ogni pausa automatica include il livello di verdetto specifico che si è attivato, l'input che lo ha innescato e un ricorso con un clic che scala a un operatore umano entro un giorno lavorativo. Preferiamo la pausa alla cancellazione; un link in pausa può essere riattivato in pochi secondi una volta completato il ricorso.
Residenza in singola regione (Agency+ e Enterprise personalizzato)
Per gli acquirenti solo-EU o solo-APAC, i clienti Agency possono richiedere:
- D1 posizionato in una singola giurisdizione (EU: EEUR o WEUR; APAC: APAC). Cloudflare rispetta un hint
locationalla creazione del database; creiamo uno shard D1 per tenant nella regione richiesta (ADR-0010). - Bucket R2 nella stessa giurisdizione, i backup cifrati notturni D1 → R2 atterrano nella regione corrispondente.
- Regione EU Zepto per l'email transazionale, configurata a livello di servizio, nessuna modifica al codice.
- KV resta globale, la replica sull'edge è fondamentale per la garanzia di redirect <50ms. Se il KV in singola regione è un requisito rigido, contattaci; possiamo valutare se una variante Worker solo-regionale è fattibile per la tua campagna.
Il prezzo per l'add-on in singola regione è a tariffa fissa (nessun markup per posto) e dipende dalla combinazione specifica. Email enterprise@abundera.ai con la giurisdizione target + il volume previsto di scansioni per un preventivo.
Postura di conformità
- GDPR, dati minimi per design (solo paese + classe dispositivo, nessun IP, nessun UA, nessun cookie) più esportazione con un clic e hard-delete in 30 giorni. DPA + SCC EU disponibili per tutti i livelli a pagamento.
- CCPA, coperto dalla stessa superficie di esportazione + eliminazione. La «vendita di dati» non è qualcosa che facciamo: nessuna condivisione con terze parti, nessun partner pubblicitario, nessun retargeting.
- SSO + provisioning SCIM, single sign-on SAML 2.0 + OIDC e lifecycle utente & gruppo SCIM 2.0 (livelli Agency + Enterprise personalizzato). Conformità RFC 7643/7644 verificata (20/20 sulla suite PingIdentity). Il flag per connessione significa che SCIM è disattivato per default e abilitato per cliente; rate-limited a 50 RPS per token; audit-logged. Okta/Entra/JumpCloud funzionano oggi come app SCIM personalizzate mentre le inserzioni nel catalogo partner sono in corso.
- SOC 2 Type II, in scoping. Processo di 6-9 mesi. Se questo è un requisito rigido per te, email enterprise@abundera.ai; possiamo condividere lo stato attuale + la timeline prevista.
- PCI-DSS, fuori scope per noi direttamente; i pagamenti sono gestiti end-to-end da Stripe (certificato PCI Level 1).
Segnalazione vulnerabilità
Hai trovato una vulnerabilità? Email security@abundera.ai. Divulgazione coordinata, confermeremo entro 24 ore (giorni lavorativi), triage entro 72 ore, e coordineremo con te una correzione + timeline di divulgazione. Nessun programma di bug bounty ancora; riconosciamo pubblicamente i ricercatori su abundera.ai/security/thanks/ una volta che la correzione è rilasciata.