𝗜 𝗔𝘂𝗱𝗶𝘁𝗲𝗱 𝗠𝘆 𝗦𝗶𝗱𝗲 𝗣𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗳𝗼𝗿 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 — 𝗛𝗲𝗿𝗲 𝗜𝘀 𝗪𝗵𝗮𝘁 𝗜 𝗙𝗼𝘂𝗻𝗱

𝗜𝗰 𝗵𝗮𝗯 𝗺𝗲𝗶𝗻𝗲 𝘀𝗶𝗱𝗲 𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗴𝗲𝗮𝘂𝗱𝗶𝘁 𝗼𝗻 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 — 𝗱𝗶𝗲 𝗵𝗶𝗲𝗿 𝗶𝘀 𝘄𝗮𝘁 𝗶𝗸 𝗵𝗲𝗯 𝗴𝗲𝘃𝗼𝗻𝗱𝗲𝗻

Onlangs heb ik al mijn side projects geaudit. Ik heb mijn FastAPI backends, Telegram bots en web apps gecontroleerd. Ik dacht dat ik voorzichtig was.

Ik had het mis.

Ik heb echte bugs gevonden die ik daadwerkelijk naar productie heb gepusht. Dit zijn geen theoretische problemen. Het zijn fouten die ik heb gemaakt terwijl ik probeerde snel te werken.

Hier zijn de belangrijkste problemen die ik heb gevonden en hoe je ze kunt oplossen:

1. Conditionele authenticatie Ik schreef code die API-keys alleen controleerde als er een secret aanwezig was. Als ik vergat de secret in mijn omgeving in te stellen, werd de controle volledig overgeslagen. Hierdoor bleef mijn API open voor iedereen.

• Oplossing: Maak authenticatie nooit conditioneel. Als de secret ontbreekt, moet de app een foutmelding geven en stoppen.

2. Lekkende keys in de Git-geschiedenis Ik vond oude API-keys in mijn Git-geschiedenis. Ik had ze later verplaatst naar .env-bestanden, maar Git bewaart elke oude versie van je code voor altijd.

• Oplossing: Behandel elke key die ooit naar Git is gecommit als gecompromitteerd. Trek deze onmiddellijk in. Gebruik tools zoals git-filter-repo om je geschiedenis op te schonen.

3. Overgebleven debug-endpoints Ik liet endpoints in productie staan die mijn databaseconfiguratie en systeeminstellingen toonden. Deze zijn handig tijdens de ontwikkeling, maar gevaarlijk in de echte wereld.

• Oplossing: Voeg het verwijderen van debug-endpoints toe aan je deployment-checklist.

4. Te gedetailleerde foutmeldingen Ik gaf ruwe systeemfouten terug aan de gebruiker. Deze fouten onthullen je bestandspaden, databasetypes en bibliotheekversies. Een aanvaller kan deze gegevens gebruiken om je systeem aan te vallen.

• Oplossing: Log de volledige fout intern voor jezelf. Stuur een generieke "Internal Server Error"-melding naar de client.

5. XSS via innerHTML Ik gebruikte innerHTML om gebruikersgegevens in mijn frontend te renderen. Dit stelt aanvallers in staat om scripts in je site te injecteren.

• Oplossing: Sanitize data altijd of gebruik textContent in plaats van innerHTML.

6. Gebrek aan rate limiting Ik had endpoints die zonder limieten dure AI-modellen aanriepen. Eén gebruiker kon in enkele minuten een enorme rekening veroorzaken.

• Oplossing: Authenticatie stopt ongeautoriseerde gebruikers. Rate limiting voorkomt dat geautoriseerde gebruikers je systeem misbruiken. Je hebt beide nodig.

7. Te ruime CORS-instellingen Ik gebruikte allow_origins=["*"] in mijn middleware. Dit staat elke website toe om verzoeken naar je API te doen.

• Oplossing: Sta in productie alleen je specifieke domeinen toe.

8. File Leakage Ik schreef code die tijdelijke bestanden aanmaakte, maar deze niet verwijderde als het proces crashte. Deze bestanden blijven voor altijd op je server staan.

• Oplossing: Gebruik een try-finally-blok om ervoor te zorgen dat bestanden worden verwijderd, zelfs als er een fout optreedt.

Beveiligingsproblemen zijn zelden opzettelijk. Ze zijn het resultaat van zeggen: "Dit fix ik later." Dat "later" komt nooit.

Integreer beveiliging vanaf dag één in je workflow. Controleer je code voordat je commit en voordat je deployt.

Bron: https://dev.to/justjinoit/i-audited-my-own-side-projects-for-security-issues-heres-what-i-found-1ahb