Torna ai Case Study
fashionAccesso Completo Sbloccato

Quattro Ruoli, un Marketplace e la Falla Trovata Prima del Lancio

Un marketplace intermediato ha quattro tipi di utente che non devono vedere i dati degli altri. Un audit pre-lancio ha trovato un percorso di registrazione pubblica che poteva diventare amministratore — prima che esistesse un solo utente pagante.

Industria moda e tessile · matching B2B intermediato

fashion
4
roles
1
critical Found
no
launched With It

!Il Bisogno

Mettere in contatto un brand moda e un produttore non è un elenco. Il buyer descrive ciò che serve, i fornitori rispondono con proposte, e un consulente sta in mezzo a modellare il brief e proteggere entrambe le parti — quindi quattro ruoli distinti con quattro viste distinte sugli stessi dati, e regole rigide su chi può vedere una proposta, un prezzo o l’identità di una controparte. Se il modello di autorizzazione è sbagliato la piattaforma non si limita a perdere dati: distrugge l’intermediazione che è la ragione della sua esistenza. Un marketplace dove un fornitore vede l’offerta di un concorrente, o un buyer scavalca il consulente, non ha più un prodotto da vendere.

L'Approccio

Abbiamo costruito la piattaforma attorno ai quattro ruoli come concetti di primo livello — buyer, fornitore, consulente e amministratore — con un wizard guidato per le richieste, un flusso di proposte e una vetrina fornitori, ciascuno che mostra solo ciò a cui il ruolo ha diritto. Poi, prima di aprire agli utenti paganti, abbiamo condotto un audit di rottura su tutte e quattro le viste invece di testare il percorso felice e cantare vittoria. È emersa una falla critica di autorizzazione: il trigger di database che crea un nuovo account si fidava dei metadati inviati dal client, così una registrazione pubblica poteva dichiararsi amministratore e prendere il controllo di qualsiasi account. Dallo stesso passaggio sono usciti altri due bypass di paywall e autorizzazioni. Il verdetto dell’audit è stato messo per iscritto come non pronto al lancio, con le falle ordinate per gravità e i percorsi principali confermati funzionanti — perché l’output utile di una revisione di sicurezza è una decisione sul lancio, non una rassicurazione.

Tecnologie Utilizzate

Next.jsSupabaseRow-level securityRole-based authorizationi18n

Il Risultato Prodotto

Quattro ruoli di primo livello — buyer, fornitore, consulente e amministratore — ciascuno con la propria vista autorizzata sui dati condivisi
Un wizard guidato per le richieste, un flusso di proposte e una vetrina fornitori, funzionanti su tutti e quattro i ruoli
Un audit di rottura completo su ogni ruolo prima di ammettere un solo utente pagante
Una falla critica di autorizzazione trovata e verificata dal vivo: una registrazione pubblica capace di dichiararsi amministratore
Altri due bypass di paywall e autorizzazioni individuati nello stesso passaggio
Un verdetto scritto di non pronto al lancio, con falle ordinate e percorsi funzionanti registrati

L'Impatto

Il percorso di takeover degli account è stato chiuso prima che potesse toccare un utente pagante
A farlo emergere è stato verificare separatamente tutte e quattro le viste di ruolo — il percorso felice passava pulito e sarebbe andato in produzione
Fidarsi dei metadati inviati dal client in un trigger di creazione account è ora un pattern noto da controllare, non una sorpresa
La decisione sul lancio è stata presa su prove scritte e non sulla sensazione che tutto sembrasse a posto
Questa piattaforma è pre-lancio e non rivendichiamo risultati che non ha prodotto — la scoperta è l’esito che vale la pena riportare

Pronto per ottenere risultati simili?

Contattaci
Supalabs AI solutions