Seguretat des del Dia 1: Els Errors OWASP Mes Comuns en Startups (i Com Evitar-los)

"Som massa petits perque ens ataquin" es la creenca mes perillosa que pot tenir un founder de startup. Les startups son atacades precisament perque son petites: menys recursos dedicats a seguretat, mes vulnerabilitats, mes facils d'explotar. Un atacant no necessita un motiu personal — un bot automatitzat escaneja milers d'aplicacions al dia buscant les vulnerabilitats mes basiques.

I les troba. En startups que van prioritzar velocitat sobre seguretat (comprensible), que van deixar la seguretat "per quan creguem" (perillos), o que simplement mai es van plantejar que algu intentaria fer SQL injection al seu endpoint de login (ingenu).

La bona noticia: la majoria de vulnerabilitats que afecten startups son conegudes, documentades i evitables. OWASP les cataloga cada any, i les mes comunes no requereixen un equip de seguretat dedicat per prevenir-les — requereixen enginyers que les coneguin i les tinguin en compte a l'hora d'escriure codi.

L'OWASP Top 10 que importa a la teva startup

OWASP publica el seu Top 10 de vulnerabilitats web regularment. No repassare les deu — em centrare en les cinc que veig amb mes frequencia en startups.

1. Broken Access Control (OWASP #1)

Es la vulnerabilitat numero u per una rao: es increiblement comuna i devastadora. Significa que un usuari pot accedir a dades o funcions que no hauria.

Exemples reals que he vist:

• Canviar l'ID a la URL (/api/users/123/orders) per veure les comandes d'un altre usuari.
• Un usuari amb rol "viewer" que pot fer peticions POST perque el backend nomes verifica permisos al frontend.
• Endpoints d'admin accessibles sense autenticacio perque "ningu coneix la URL".

Com evitar-ho:

• Verifica autoritzacio a cada endpoint del backend. Mai confiis en el frontend per controlar l'acces. El frontend es una suggerencia visual; el backend es la llei.
• Implementa RBAC (Role-Based Access Control) des del principi. No "quan tinguem mes rols". Des del principi.
• Denega per defecte. Cada endpoint hauria de requerir autenticacio i autoritzacio explicita. Si t'oblides de protegir un endpoint, que falli cap a segur, no cap a obert.
• Testeja l'autoritzacio. Escriu tests que intentin accedir a recursos amb l'usuari equivocat. Si aquests tests no existeixen, aquestes vulnerabilitats probablement si.

2. Injection (OWASP #3)

SQL injection existeix des de fa mes de 20 anys, i segueix apareixent. Tambe NoSQL injection, command injection, i LDAP injection. El patro es sempre el mateix: input de l'usuari que s'interpreta com a codi.

-- Si construeixes queries aixi, estas 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. Cada ORM modern (Prisma, SQLAlchemy, Sequelize, TypeORM) les fa servir per defecte. Si estas escrivint SQL raw amb concatenacio de strings, para.
• Validacio d'input. Tot el que ve de l'usuari es sospitos. Valida tipus, longituds, formats. No nomes al frontend — al backend tambe.
• Principi de minim privilegi a la base de dades. La teva aplicacio no hauria de connectar-se a la base de dades amb un usuari que pugui fer DROP TABLE. Crea usuaris amb permisos limitats al que l'aplicacio necessita.

3. Insecure Design (OWASP #4)

Aquesta es mes subtil i mes dificil d'arreglar despres. No es un bug d'implementacio — es una fallada de disseny. La seguretat es va pensar com un afterthought, no com a part del disseny.

Exemples:

• Un sistema de reset de contrasenya que envia la nova password per email en text pla.
• Una API que retorna tots els camps de l'usuari (inclos el hash de contrasenya) perque "el frontend ja filtra el que mostra".
• Un flux de checkout que confia en el preu que envia el client en lloc de calcular-lo al servidor.

Com evitar-ho:

• Threat modeling durant el disseny. Abans d'escriure codi, pregunta: "com podria algu abusar d'aixo?". No necessites un framework formal — una conversa de 15 minuts a la pissarra es millor que res.
• Mai confiis en el client. Tot el que ve del frontend es un input, no una font de veritat. Preus, permisos, identitats — tot es valida i calcula al servidor.
• Principi de minima exposicio. La teva API hauria de retornar exactament les dades necessaries, no tot l'objecte de la base de dades. Fes servir DTOs o serializers que controlin quins camps s'exposen.

4. Security Misconfiguration (OWASP #5)

La configuracio insegura es el resultat de les presses. No es que algu decides ser insegur — es que ningu va revisar els defaults.

Els hits mes frequents:

• Credencials per defecte a bases de dades, panells d'admin, o serveis.
• Buckets de S3 publics amb dades d'usuaris. Aixo segueix passant el 2024.
• Missatges d'error verbosos en produccio que revelen stack traces, versions de programari, o estructura de la base de dades.
• CORS configurat com * en produccio perque "aixi funciona" durant desenvolupament.
• Headers de seguretat absents: sense HSTS, sense Content-Security-Policy, sense X-Frame-Options.

Com evitar-ho:

• Checklist de seguretat abans de cada deploy. No cal que sigui llarg. Deu punts que es revisen sistematicament.
• Entorns de desenvolupament i produccio amb configuracions diferents. Els missatges d'error detallats son utils en dev. En produccio, retorna un error generic i logueja els detalls internament.
• Audita els teus serveis cloud regularment. Eines com AWS Trusted Advisor, ScoutSuite o Prowler escanegen la teva infraestructura buscant misconfiguracions.

5. Vulnerable and Outdated Components (OWASP #6)

La teva aplicacio te desenes (o centenars) de dependencies. Cadascuna es una superficie d'atac potencial. Una dependencia desactualitzada amb un CVE conegut es una porta oberta amb un cartell que diu "entreu aqui".

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 similar.

Com evitar-ho:

• Dependabot o Renovate per a actualitzacions automatiques de dependencies. Configura-ho des del dia u. No costa res i preveu el mes obvi.
• Snyk o npm audit al teu pipeline de CI. Que el build falli si hi ha una vulnerabilitat critica coneguda. Si, a vegades es incomode. Menys incomode que una bretxa de dades.
• Revisa el que instal·les. Abans de fer npm install paquet-random, mira quantes descargues te, quan es va actualitzar per ultima vegada, qui el mante. Les llibreries abandonades son bombes de rellotgeria.

Quick wins: seguretat basica per a qualsevol startup

No necessites ser un expert en seguretat per implementar aixo. Son coses que qualsevol equip d'enginyeria hauria de fer per defecte:

• HTTPS a tot arreu. Sense excepcions. Let's Encrypt es gratuit. No hi ha excusa per HTTP el 2024.
• Hashing de contrasenyes amb bcrypt o Argon2. Si estas fent servir MD5 o SHA256 sense salt per a passwords, para ara mateix.
• Rate limiting a endpoints d'autenticacio. Login, registre, reset de contrasenya. Sense rate limiting, un bot pot provar milers de contrasenyes per minut.
• CORS configurat correctament. Nomes els origens que necessites, no *.
• Secrets a variables d'entorn. Mai al codi, mai al repo. Si la teva API key de Stripe esta en un arxiu .env commitejat, ja estas compromes.
• Actualitzacions de dependencies regulars. Setmanalment o com a minim mensualment.
• Logs d'acces i autenticacio. Necessites saber qui va intentar accedir a que i quan. Es basic per a resposta a incidents.

Checklist pre-llancament

Abans que la teva aplicacio vegi un usuari real, verifica:

• Tots els endpoints requereixen autenticacio (excepte els que explicitament no han de fer-ho)
• L'autoritzacio es verifica al backend, no nomes al frontend
• No hi ha credencials hardcodeades al codi
• Els errors en produccio no exposen informacio interna
• HTTPS esta forcat a tots els entorns
• Les dependencies no tenen CVEs critics coneguts
• Rate limiting esta actiu a endpoints sensibles
• Els backups estan configurats i testejats (si, testejats — un backup que no es pot restaurar no es un backup)
• Els logs d'autenticacio estan actius

No es exhaustiu, pero cobreix els fonaments que la majoria de startups ignoren.

La seguretat com a habit d'enginyeria

La seguretat no s'implementa en un sprint abans de l'auditoria. Es construeix com a habit, a cada pull request, a cada decisio de disseny. Els enginyers senior que integren la seguretat al seu proces de desenvolupament no son mes lents — son mes eficients, perque no generen deute de seguretat que algu ha de pagar despres.

A Conectia, els enginyers que integrem al teu equip tracten la seguretat com a part del desenvolupament, no com un checklist extern. Construeixen amb OWASP en ment des del primer commit, configuren pipelines amb escaneig de dependencies, i dissenyen APIs que fallen cap a segur. Perque un incident de seguretat en una startup primerenca pot costar molt mes que diners — pot costar la confianca dels teus primers usuaris.

---

El teu equip d'enginyeria te la seguretat integrada al seu proces de desenvolupament? Parla amb un CTO — integrem enginyers senior que construeixen segur per defecte, no com a afterthought.