5 Security Checks Every Developer Should Do Before Shipping

Oh yes, I know the story, you have spent weeks building something great. You have surveyed the market and validated the audience. You have tested the features. You have squashed the bugs. You are ready to ship this off...wait, but is it truly secure?

I have previously been in this position too and believe you me securing my application felt like the most tedious and overwhelming aspect and really took me out of the creative aspect of Application-layer vulnerabilities still account for the majority of modern breaches and this is partly because security is still viewed in many circles as an afterthought in software development. The truth is there is nothing quite as assured as a pen test and that is not just a biased pro-pentesting agenda (as I am a pentester myself) but there are a handful of quick checks that you can definitely do before committing your code/application/software to production, which can actually save you hours of patching, public scrutiny and can help pinpoint the scope of assessment you might want pentesters to probe - potentially saving you some money too. This isn't about being paranoid - it is about being prepared!

Here are 5 essential security checks I believe every developer should do before launch:

✅ 1.Input Sanitisation & Validation

Poor validation can lead to XSS, SQLi and malicious command injection. These are some of the best ways to correct this:

• Never trust user input—validate it at both client-side and server-side.
• Use strict allow-lists (whitelists) instead of blocklists (blacklists).
• When possible, use libraries like DOMPurify for the frontend and parameterised queries for the backend.

*🧪 Pro Tip: Assume all user input is hostile until proven safe—sanitize everything

// ❌  Insecure: user input directly inserted into HTML
document.body.innerHTML = "<div>" + userInput + "</div>";

// 💟 Secure: using DOMPurify to sanitize
document.body.innerHTML = DOMPurify.sanitise(userInput);

✅ 2.Harden your API Layer

Unauthenticated and unauthorised APIs can be abused. These are some of the best ways to correct this:

• Require authentication on all endpoints
• Enforce rate limiting (e.g. only allowing 2 requests per second) and input validation (once again!)
• Log suspicious behaviour AND regularly review logs.

*🧪 Pro Tip: If an API endpoint doesn’t require authentication, assume someone will abuse it!

✅ 3.Secure your Sessions and Tokens

Attackers can take advantage of insecure session and token handling to commit session hijacking and cookie reuse to gain unauthorised access. These are some of the best ways to correct this:

• Set HttpOnly, Secure, and SameSite attributes on cookies to prevent theft.
• Regenerate session tokens after login, logout, or privilege elevation.
• Do not allow concurrent sessions to exist, especially within the same browser.
• Avoid storing sensitive tokens, like JWTs, in localStorage (consider session-only cookies).
• Implement session timeouts and auto-expiration for inactive users.

*🧪 Pro tip: Set short lifespans for tokens and rotate them often.

✅ 4.Audit Your Dependencies

What does this mean? Check all the third-party libraries and packages your app uses. Thoroughly. Not doing so can lead to supply chain attacks, which are evidently on the rise.

• Run security audits and scans such as npm audit (node.js/js), yarn audit (node.js/js) and pip-audit (python)
• Alternatively consult commercial tools such as Snyk or Github Dependabot to scan for CVEs.
• Watch for vulnerable transitive dependencies (your dependencies' dependencies)

*🧪 Pro tip: You're only as strong as your weakest package.

✅ 5.Keep Secrets Out of Your Codebase

Leaked API keys, database credentials, or admin tokens stored in your code can instantly expose your entire system if pushed to a public repo — and don't be fooled, attackers are scanning GitHub regularly for exactly these kinds of mistakes. These are some of the best ways to correct this:

• NEVER STORE HARDCODE secrets like API keys, database passwords, JWT secrets, or private tokens directly into your source files.
• Add .env, secrets.json, and *.pem to your .gitignore to ensure they’re never accidentally committed to version control.
• Run secret scanners like Gitleaks or truffleHog before pushing code.

*🧪 Pro tip: If you’ve accidentally pushed a secret, revoke it immediately — deleting the commit isn’t enough. Git history lives forever.

To summarise, you do not necessarily need to be a security expert, but it is something you have to care about especially in the wake of this AI arms race and in the evolving cybersecurity landscape. Implementing small changes such as the ones aforementioned really go a long way. The general posture towards security implementations should be zero trust and assuming the worst that can be done by an attacker...this should help you prepare effectively. Try to start looking and implementing early.

Secure code is shipped code!