Seguretat des del primer dia: els errors OWASP més comuns a les startups (i com evitar-los)
«Som massa petits perquè ens ataquin» és la creença més perillosa que pot tenir el fundador d'una startup. Les startups reben atacs precisament perquè són petites: menys recursos dedicats a la seguretat, més vulnerabilitats, més fàcils d'explotar. Un atacant no necessita cap motiu personal — un bot automatitzat escaneja cada dia milers d'aplicacions a la recerca de les vulnerabilitats més bàsiques.
I les troba. Ho he vist en startups que prioritzaven la velocitat per sobre de la seguretat (comprensible), que deixaven la seguretat «per a quan creixem» (perillós), o que senzillament mai no s'havien plantejat que algú provaria una injecció SQL al seu endpoint de login (ingenu).
La bona notícia: la majoria de vulnerabilitats que afecten les startups són conegudes, estan ben documentades i es poden evitar. Fa més de dues dècades que OWASP les cataloga, i les més habituals no demanen un equip de seguretat dedicat per prevenir-les — demanen enginyers que les coneguin i les tinguin presents quan escriuen codi.
El Top 10 d'OWASP que importa a la teva startup
OWASP publica periòdicament el seu Top 10 de vulnerabilitats web. No les repassaré totes deu — em centraré en les cinc que veig més sovint a les startups.
1. Broken Access Control (OWASP #1)
És la vulnerabilitat número u per una raó: és increïblement comuna i devastadora. Vol dir que un usuari pot accedir a dades o funcionalitats a què no hauria de tenir accés.
Exemples reals que he vist:
- Canviar l'ID de la URL (
/api/users/123/orders) per veure les comandes d'un altre usuari. - Un usuari amb rol «viewer» que pot fer peticions POST perquè el backend només comprova els permisos al frontend.
- Endpoints d'administració accessibles sense autenticació perquè «ningú no sap la URL».
Com evitar-ho:
- Verifica l'autorització a cada endpoint del backend. No et refiïs mai del frontend per controlar l'accés. El frontend és un suggeriment visual; el backend és la llei.
- Implementa RBAC (Role-Based Access Control) des del principi. No «quan tinguem més rols». Des del principi.
- Denega per defecte. Cada endpoint hauria d'exigir autenticació i autorització explícites. Si t'oblides de protegir un endpoint, que falli del costat segur, no de l'obert.
- Testeja l'autorització. Escriu tests que intentin accedir a recursos amb l'usuari equivocat. Si aquests tests no existeixen, aquestes vulnerabilitats probablement sí.
2. Injection (OWASP #3)
La injecció SQL fa més de vint anys que existeix, i encara apareix. També la injecció NoSQL, la injecció d'ordres i la d'LDAP. El patró és sempre el mateix: input de l'usuari que acaba interpretat com a codi.
-- Si construeixes les queries així, estàs exposat:
SELECT * FROM users WHERE email = '" + userInput + "'
-- Un atacant envia: ' OR '1'='1
-- I accedeix a tots els usuaris.
Com evitar-ho:
- Queries parametritzades, sempre. Sense excepcions. Qualsevol ORM modern (Prisma, SQLAlchemy, Sequelize, TypeORM) les fa servir per defecte. Si escrius SQL a pèl concatenant strings, atura't.
- Validació de l'input. Tot el que ve de l'usuari és sospitós. Valida tipus, longituds, formats. No només al frontend — també al backend.
- Mínim privilegi a la base de dades. La teva aplicació no s'hauria de connectar a la base de dades amb un usuari capaç de fer DROP TABLE. Crea usuaris amb els permisos limitats al que l'aplicació necessita de debò.
3. Insecure Design (OWASP #4)
Aquesta és més subtil i més difícil d'arreglar a posteriori. No és un bug d'implementació — és un defecte de disseny. La seguretat es va tractar com un afegit de darrera hora, no com a part del disseny.
Exemples:
- Un sistema de restabliment de contrasenya que envia la contrasenya nova per correu en text pla.
- Una API que retorna tots els camps de l'usuari (hash de la contrasenya inclòs) perquè «el frontend ja filtra el que mostra».
- Un flux de checkout que es creu el preu que envia el client en comptes de calcular-lo al servidor.
Com evitar-ho:
- Threat modeling durant el disseny. Abans d'escriure codi, pregunta't: «com podria algú abusar d'això?». No necessites cap framework formal — una conversa de quinze minuts davant la pissarra és millor que res.
- No et creguis mai el client. Tot el que arriba del frontend és input, no una font de veritat. Preus, permisos, identitats — tot es valida i es calcula al servidor.
- Principi de mínima exposició. La teva API hauria de retornar exactament les dades necessàries, no l'objecte sencer de la base de dades. Fes servir DTOs o serialitzadors per controlar quins camps s'exposen.
4. Security Misconfiguration (OWASP #5)
La configuració insegura és filla de les presses. No és que algú decidís ser insegur — és que ningú no va revisar els valors per defecte.
Els clàssics:
- Credencials per defecte a bases de dades, panells d'administració o serveis.
- Buckets d'S3 públics amb dades d'usuaris. Això encara passa el 2024.
- Missatges d'error verbosos en producció que revelen stack traces, versions de programari o l'estructura de la base de dades.
- CORS configurat amb
*en producció perquè «així funcionava» durant el desenvolupament. - Capçaleres de seguretat absents: ni HSTS, ni Content-Security-Policy, ni X-Frame-Options.
Com evitar-ho:
- Checklist de seguretat abans de cada desplegament. No cal que sigui llarga. Deu punts que es revisen sistemàticament.
- Configuracions separades per a dev i producció. Els missatges d'error detallats són útils en dev. En producció, retorna un error genèric i registra els detalls internament.
- Audita els teus serveis al núvol regularment. Eines com AWS Trusted Advisor, ScoutSuite o Prowler escanegen la teva infraestructura a la recerca d'errors de configuració.
5. Vulnerable and Outdated Components (OWASP #6)
La teva aplicació té desenes (o centenars) de dependències. Cadascuna és una superfície d'atac potencial. Una dependència desactualitzada amb un CVE conegut és una porta oberta amb un rètol que diu «passeu, passeu».
Recordes Log4Shell? Una vulnerabilitat en una llibreria de logging de Java que va afectar mig internet. La teva startup probablement fa servir desenes de llibreries amb un nivell d'escrutini semblant.
Com evitar-ho:
- Dependabot o Renovate per actualitzar dependències automàticament. Configura-ho des del dia u. No costa res i caça els problemes més evidents.
- Snyk o npm audit al pipeline de CI. Fes que el build falli si hi ha una vulnerabilitat crítica coneguda. Sí, de vegades és incòmode. Menys incòmode que una filtració de dades.
- Revisa el que instal·les. Abans de fer
npm install paquet-aleatori, mira quantes baixades té, quan es va actualitzar per última vegada i qui el manté. Les llibreries abandonades són bombes de rellotgeria.
Quick wins: seguretat de base per a qualsevol startup
No cal ser expert en seguretat per aplicar tot això. Són coses que qualsevol equip d'enginyeria hauria de fer per defecte:
- HTTPS pertot arreu. Sense excepcions. Let's Encrypt és gratuït. No hi ha cap excusa per anar per HTTP el 2024.
- Hash de contrasenyes amb bcrypt o Argon2. Si fas servir MD5 o SHA256 sense salt per a les contrasenyes, atura't ara mateix.
- Rate limiting als endpoints d'autenticació. Login, registre, restabliment de contrasenya. Sense rate limiting, un bot pot provar milers de contrasenyes per minut.
- CORS ben configurat. Només els orígens que necessites, no
*. - Secrets a variables d'entorn. Mai al codi, mai al repositori. Si la teva clau d'API d'Stripe és en un fitxer
.envcommitejat, ja estàs compromès. - Actualitzacions de dependències regulars. Cada setmana o, com a mínim, cada mes.
- Logs d'accés i d'autenticació. Has de poder saber qui ha intentat accedir a què i quan. És fonamental per respondre a incidents.
Checklist abans de llançar
Abans que la teva aplicació arribi al primer usuari real, comprova:
- Tots els endpoints requereixen autenticació (tret dels que explícitament han de ser públics)
- L'autorització es verifica al backend, no només al frontend
- No hi ha credencials hardcodejades al codi
- Els errors en producció no exposen informació interna
- HTTPS és obligatori a tots els entorns
- Les dependències no tenen CVE crítics coneguts
- El rate limiting és actiu als endpoints sensibles
- Els backups estan configurats i provats (sí, provats — un backup que no es pot restaurar no és un backup)
- Els logs d'autenticació estan actius
No és exhaustiva, però cobreix els fonaments que la majoria de startups passen per alt.
La seguretat com a hàbit d'enginyeria
La seguretat no s'implementa en un sprint just abans de l'auditoria. Es construeix com un hàbit, a cada pull request, a cada decisió de disseny. Els enginyers sènior que integren la seguretat al seu procés de desenvolupament no són més lents — són més eficients, perquè no generen un deute de seguretat que algú haurà de pagar més endavant.
A Conectia, els enginyers que integrem al teu equip tracten la seguretat com a part del desenvolupament, no com una checklist externa. Construeixen amb OWASP al cap des del primer commit, munten pipelines amb escaneig de dependències i dissenyen APIs que fallen del costat segur. Perquè un incident de seguretat en una startup en fase inicial pot costar molt més que diners — pot costar-te la confiança dels primers usuaris.
El teu equip d'enginyeria té la seguretat integrada al procés de desenvolupament? Parla amb un CTO — integrem enginyers sènior que construeixen segur per defecte, no com un pedaç de darrera hora.
