𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗔𝘂𝗱𝗶𝘁 𝗥𝗲𝘀𝘂𝗹𝘁𝘀: 𝗪𝗵𝘆 𝗜 𝗳𝗲𝗹 𝗲𝗺𝗯𝗮𝗿𝗿𝗮𝘀𝘀𝗲𝗱
I recently ran a security audit on all my side projects. This includes my FastAPI backend, Telegram bots, PWA, and Streamlit apps.
I thought my code was safe because I was careful. I was wrong.
I am sharing these real production bugs to help you avoid them. These are not theoretical checklists. These are mistakes I actually made.
The Conditional Authentication Trap I wrote code that checked if an API secret existed before verifying it. If the environment variable was missing, the check skipped entirely. This meant my entire API was open to the public. Rule: If a secret is missing, fail hard with a 500 error. Never skip authentication.
The Git History Leak I once hardcoded an API key for a quick test. I moved it to a .env file later and thought it was fixed. But Git remembers everything. Anyone can find that key in my commit history. Rule: If you commit a key, assume it is stolen. Rotate it immediately. Use git-filter-repo to clean your history.
The Debug Endpoint Leak I left a /debug/config endpoint in production to help me troubleshoot. It exposed my database URLs and environment settings. Rule: Remove all debug endpoints before deployment. Use logs instead.
Leaking System Info via Errors I used str(e) in my error responses. This sent database errors and file paths directly to the user. Attackers use this to map your infrastructure. Rule: Log the detailed error for yourself. Send a generic "Internal Server Error" to the client.
The XSS Risk in Frontend I used innerHTML to render user content. This allowed scripts to run in other users' browsers. Rule: Always escape HTML. Treat innerHTML as a way to execute arbitrary code.
Missing Rate Limits I had endpoints that called expensive AI models without any limits. A single loop or a stolen key could cost me hundreds of dollars. Rule: Authentication stops unauthorized users. Rate limiting stops authorized users from abusing your system.
Permissive CORS Policy I used allow_origins=["*"] in production. This allows any site to make requests to your API. Rule: Only allow your specific frontend domain.
ತಾತ್ಕಾಲಿಕ ಫೈಲ್ ಸೋರಿಕೆ ಒಂದು ಫೈಲ್ ಅನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡುವಾಗ ನನ್ನ ಕೋಡ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ, ಆ ತಾತ್ಕಾಲಿಕ ಫೈಲ್ ಶಾಶ್ವತವಾಗಿ ಡಿಸ್ಕ್ನಲ್ಲಿ ಉಳಿಯುತ್ತಿತ್ತು. ಇದು ಜಾಗವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಸೋರಿಕೆ ಮಾಡುತ್ತದೆ. ನಿಯಮ: ದೋಷ ಸಂಭವಿಸಿದರೂ ಸಹ ಫೈಲ್ಗಳು ಅಳಿಸಲ್ಪಡುವಂತೆ ಮಾಡಲು
try-finallyಬ್ಲಾಕ್ಗಳನ್ನು ಬಳಸಿ.
ನನ್ನ ಹೊಸ ಕಡ್ಡಾಯ ಚೆಕ್ಲಿಸ್ಟ್:
ಕೋಡಿಂಗ್ ಮಾಡುವ ಮೊದಲು:
• .gitignore ಅನ್ನು ರಚಿಸಿ
• .env.example ಅನ್ನು ರಚಿಸಿ
ಪ್ರತಿ ಎಂಡ್ಪಾಯಿಂಟ್ಗಾಗಿ (endpoint): • ಅಥೆಂಟಿಕೇಶನ್ (authentication) ಸೇರಿಸಿ • ಸಾಮಾನ್ಯ ದೋಷ ಸಂದೇಶಗಳನ್ನು (generic error messages) ಬಳಸಿ • ಹೆಚ್ಚು ಸಂಪನ್ಮೂಲ ಬಳಸುವ ಕಾರ್ಯಗಳಿಗೆ ರೇಟ್ ಲಿಮಿಟ್ಗಳನ್ನು (rate limits) ಸೇರಿಸಿ
ಕಮಿಟ್ (commit) ಮಾಡುವ ಮೊದಲು: • ನಿಮ್ಮ ಡಿಫ್ (diff) ನಲ್ಲಿ ರಹಸ್ಯ ಮಾಹಿತಿ (secrets) ಇದೆಯೇ ಎಂದು ಸ್ಕ್ಯಾನ್ ಮಾಡಿ
ಡಿಪ್ಲಾಯ್ (deploy) ಮಾಡುವ ಮೊದಲು: • ನಿಮ್ಮ ಡಿಪೆಂಡೆನ್ಸಿಗಳ (dependencies) ಮೇಲೆ ಸೆಕ್ಯೂರಿಟಿ ಆಡಿಟ್ಗಳನ್ನು ನಡೆಸండి
ಭದ್ರತಾ ಸಮಸ್ಯೆಗಳು ಆಕಸ್ಮಿಕವಾಗಿ ಸಂಭವಿಸುವುದಿಲ್ಲ. ಅವು "TODO" ಕಾಮೆಂಟ್ಗಳು ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ (production) ಶಾಶ್ವತವಾಗಿ ಉಳಿಯುವ "ತಾತ್ಕಾಲಿಕ" ಪರಿಹಾರಗಳಿಂದ ಸಂಭವಿಸುತ್ತವೆ.
ಬಗ್ (bug) ಸರಿಪಡಿಸುವುದು ಬೇಸರ ತರಿಸಬಹುದು. ಆದರೆ ಭದ್ರತಾ ಉಲ್ಲಂಘನೆಯನ್ನು (breach) ಸರಿಪಡಿಸುವುದು ದುಬಾರಿಯಾಗುತ್ತದೆ.