How to Run a Security Audit When You Don't Have a Security Team

Most security advice is written for companies that already have a security team. Threat modeling workshops, red team exercises, formal penetration tests — these are genuinely useful, but they're not accessible to a solo founder shipping a SaaS product between customer calls.

The good news: the vulnerabilities most likely to sink a startup aren't sophisticated. They're basic misconfigurations and omissions that show up on every security checklist. You don't need a security expert to find them — you need a systematic process and the right tools.

What a DIY Security Audit Actually Covers

A proper penetration test tries to exploit every possible vulnerability using the techniques a skilled attacker would use. That requires deep expertise and is appropriately expensive.

A DIY security audit is different. It's a structured review of your most likely attack surface using automated tools, checklists, and a methodical approach. It won't catch every vulnerability, but it will catch the low-hanging fruit that attackers target first — and that's where most breaches actually happen.

The goal isn't perfection. It's a known, documented security posture that's meaningfully better than nothing.

Step 1: External Surface Scan (30 minutes)

Start where attackers start: outside your system, looking at what's exposed to the internet. You want to understand your external attack surface before diving into code.

Run an external security scan on every production URL your application exposes. This will surface:

TLS/SSL configuration issues (weak ciphers, expired certificates, TLS version)
Missing security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
Exposed endpoints that shouldn't be accessible (admin panels, debug routes, internal APIs)
CORS misconfigurations
Server information disclosure

Tools like Scantient's free scanner let you do this in under a minute without any code access. SecurityHeaders.com can audit your headers specifically. SSL Labs can test your TLS configuration.

Fix every critical and high finding from this step before moving on. These are the issues attackers will find in seconds.

Step 2: Secrets and Credential Audit (45 minutes)

Leaked credentials are the most common cause of startup security incidents — and they're completely preventable. This step involves auditing everywhere secrets might have been accidentally exposed.

Git history scan: Run git log -p | grep -i 'api_key\|secret\|password\|token' or use a tool like trufflesecurity/trufflehog to scan your entire commit history. Secrets committed once and deleted are still in your git history.
Environment file audit: Confirm that .env files are in your .gitignore and have never been committed. Check your public GitHub repos specifically.
Hardcoded credential check: Search your codebase for common secret patterns — API keys, passwords, connection strings. Your IDE's global search is sufficient for small codebases.
Production environment verification: Confirm production secrets are stored in your cloud provider's secrets manager, not in plaintext config files on the server.

If you find any secrets in git history, rotate them immediately — then clean the history (though rotation is more urgent than the cleanup).

Step 3: Authentication and Authorization Review (60 minutes)

Authentication failures are consistently in the OWASP Top 10 API risks because they're common and high-impact. Walk through your authentication implementation looking for:

Unauthenticated endpoints: Review every API route. Any route that returns user data or performs actions without requiring authentication is a critical finding. Map your routes and test each one with an unauthenticated curl request.
Authorization checks: Beyond authentication (are you who you say you are?), test authorization (can you access this resource?). Try accessing another user's resources with your own authenticated token. If GET /api/invoices/123 works when invoice 123 belongs to a different user, you have an IDOR vulnerability.
Token security: If you use JWTs, verify you're using a strong algorithm (RS256 or HS256 with a strong secret), setting expiry, and not storing sensitive data in the payload.
Admin access: Confirm that admin-only functionality requires elevated authentication and that regular user tokens cannot access admin endpoints.

Start with the external scan — it takes 60 seconds

Scantient scans your production API from the outside, just like an attacker would. Get a security score and prioritized findings — free, no signup.

Scan Your API Free →

Step 4: Dependency Vulnerability Scan (30 minutes)

Your application depends on dozens of open-source libraries. Any of them could have known vulnerabilities. This is a quick win because the tooling is excellent and mostly free.

Run npm audit (or yarn audit) and review the output. Critical and high severity findings need immediate action — they typically have known exploits.
Check GitHub's Dependabot alerts on your repositories. If you haven't reviewed these recently, some may have been outstanding for months.
Add dependency scanning to your CI/CD pipeline so new vulnerabilities are automatically surfaced. npm audit in your GitHub Actions workflow is two lines of configuration.

Step 5: Input Validation and Injection Testing (45 minutes)

Injection vulnerabilities — SQL injection, command injection, and their modern variants — are preventable but still common. Test your API's input handling by:

Sending special characters in all user-controlled fields: single quotes ('), double quotes ("), angle brackets, null bytes, very long strings. Watch for unexpected errors that reveal database queries or stack traces.
Testing your search endpoints with SQL-like strings: 1' OR '1'='1. Any response that differs from a normal invalid input warrants investigation.
Verifying that file upload endpoints (if any) validate file type and don't execute uploaded content.

If you're using an ORM (Prisma, SQLAlchemy, ActiveRecord) and parameterized queries throughout, your SQL injection risk is low. The concern is custom SQL or raw query construction in edge cases.

Step 6: Rate Limiting and Abuse Prevention (20 minutes)

Verify that your API has rate limiting on:

Authentication endpoints (login, password reset, magic link)
Account creation (to prevent fake account abuse)
Any endpoint that triggers an email or SMS (prevent toll fraud)
Your most expensive API operations (prevent abuse-related cost spikes)

Test it: send 20 rapid-fire requests to your login endpoint and verify you get rate limited. If you don't, that's an immediate fix.

Document Your Findings

A security audit is only valuable if you track and fix what you find. After each step:

Create a GitHub issue (or linear/notion ticket) for every finding
Label by severity: Critical, High, Medium, Low
Assign Critical and High findings to the current sprint
Document what you tested and what the results were — this is your audit evidence

This documentation matters beyond the immediate fixes. If you're ever asked by a customer, investor, or regulator about your security posture, you want receipts — not just verbal assurances.

Make It Repeatable

A one-time audit has limited value. Security is a continuous process, not a point-in-time checkbox. After your first audit:

Schedule a monthly review of the security checklist — it takes 30 minutes once you've done it once
Set up automated external scanning so you're alerted when your security posture degrades
Add dependency scanning to your CI/CD pipeline for continuous coverage
Review the indie dev security checklist before every major release

DIY Security Audit: Master Checklist

✅ External surface scan: TLS, headers, exposed endpoints
✅ Git history scanned for secrets
✅ .env files excluded from version control
✅ Production secrets in secrets manager, not config files
✅ All endpoints require authentication where appropriate
✅ Authorization tested: user A cannot access user B's resources
✅ Admin endpoints require elevated auth
✅ JWT algorithm and expiry verified
✅ npm audit run; critical/high findings resolved
✅ Dependency scanning added to CI/CD
✅ Input validation tested on all user-controlled fields
✅ Rate limiting on auth and sensitive endpoints
✅ Findings documented and tracked in issue tracker
✅ Monthly review scheduled

For a complete pre-launch security checklist organized by category, see the SaaS launch security checklist.