The most dangerous sentence in a small company's security posture is "we're too small for anyone to bother." It feels true. It is completely wrong.

The attackers that hit small sites are almost never people. They're scripts. Bots crawl the entire internet looking for a known-vulnerable dependency, an admin endpoint with no auth, a leaked API key in a public commit, a login form with no rate limit. They don't know your revenue and they don't care. To an automated scanner, a solo founder's side project and a Fortune 500 API look identical: an IP address and a list of open doors.

The good news is that the same fact that makes you a target makes you defensible. Automated attacks go after known, common mistakes. You don't need a security team to close known, common mistakes. You need a checklist and a habit.

Here's the checklist I keep, why each item matters, and, because this is the fastest era in history to get a second set of eyes, the LLM prompts I use to work through it.

What you're actually protecting

It's worth being concrete about the stakes, because "security" in the abstract never makes it onto the roadmap. Four things are on the line:

  • Your customers. Their data and their trust. A breach is often the one mistake a small brand doesn't recover from, because trust was the whole moat.
  • Your enterprise deals. The moment you sell to a company of any size, their procurement team sends a security questionnaire. "We don't really do security" ends the conversation. Being able to answer well is a growth lever, not a cost.
  • Your intellectual property. Everything you spent nights building lives here: the source, the data, and whatever models or corpus you scraped or curated.
  • Your compliance obligations. Depending on who you serve, you may already be on the hook for GDPR, CCPA, PCI (if you touch card data), or contractual security terms you signed without a lawyer.

None of that requires a big program. It requires not leaving the common doors open.

The checklist

1. Dependencies and supply chain

Most real-world breaches of small apps start in code you didn't write.

  • Run your ecosystem's audit tool on a schedule (npm audit, pip-audit, cargo audit, bundler-audit). Wire it into CI so a critical CVE fails the build.
  • Commit your lockfile and treat it as source of truth. Reproducible installs are a security property, not just a convenience.
  • Before adding a dependency, look at it: how many maintainers, when was the last release, how many transitive packages does it drag in. Every dependency is a trust decision.
  • When a fix requires a major version bump, do it deliberately, but don't let "it's a breaking change" become a reason to ship a known-vulnerable library for months.

2. Secrets

  • Keep keys in environment variables or a secrets manager. Never in source, never in the client bundle, never in logs.
  • Make sure your .env files are gitignored, and scan your history: a secret committed once is a secret leaked forever, even if a later commit removes it. Rotate anything that ever touched a repo.
  • Turn on your host's push protection / secret scanning. It's free and it has caught more leaks than any code review.
  • Prefer sending credentials in headers over URL query strings, because URLs end up in access logs and error trackers.

3. Authentication and authorization

Authentication is "who are you." Authorization is "what are you allowed to do." Small apps get the first right and the second wrong constantly.

  • Verify the session on the server for every protected route. Never trust a role or a user id that arrives in the request body.
  • Guard every admin and internal endpoint individually. A common and painful gotcha: page-level guards in many frameworks do not automatically protect your API routes. The pretty admin dashboard is locked; the API it calls is wide open.
  • Enforce least privilege. A logged-in user is not an admin. An admin action should check the admin role, not merely that someone is signed in.
  • Rate-limit anything that authenticates, sends email, or costs you money per call (especially anything that hits a paid AI API).

4. Untrusted input: treat all of it as hostile

Anything from a user, a URL, an uploaded file, or a third-party feed is attacker-controlled until you've proven otherwise. This is where injection and cross-site scripting live.

  • Use parameterized queries for every database call. String-concatenated SQL is the oldest mistake in the book and still the most common.
  • Escape or sanitize any third-party or user content before rendering it as HTML. Framework auto-escaping saves you until the first time you reach for a raw-HTML rendering escape hatch. Those spots need a real sanitizer.
  • Validate URLs before putting them in a link or fetching them. Reject anything that isn't http(s); a javascript: link is a script waiting to run.
  • Never build a shell command by pasting in user input. Pass arguments as an array to the process directly, without a shell.
  • Constrain file paths to an allowlisted directory. A path check that only confirms "inside my project" still lets an attacker overwrite your own code.

5. Transport and security headers

  • Serve everything over HTTPS and turn on HSTS.
  • Add the cheap, non-breaking headers today: X-Content-Type-Options: nosniff, a clickjacking guard (X-Frame-Options / CSP frame-ancestors), and a sensible Referrer-Policy.
  • Work toward a real Content-Security-Policy. It's the single strongest defense against XSS, but it needs tuning against your actual assets, so roll it out in report-only mode first and watch what breaks before you enforce it.

6. Data minimization and least privilege

  • Don't collect data you don't need. Data you never stored can't leak.
  • Give each process and database account the narrowest permissions that let it do its job.
  • Have a retention and deletion policy, even a one-paragraph one. Enterprise questionnaires ask, and regulators expect it.

7. Backups and recovery

  • Automate backups of anything you can't recreate, and test a restore. An untested backup is a hope, not a plan.
  • Write down how you'd recover from a compromised key, a bad deploy, or a lost database. You do not want to be improvising that at 2 a.m.

8. Logging and monitoring

  • Log auth failures, admin actions, and errors, but scrub secrets and personal data out of what you log.
  • Set one or two alerts you'll actually notice: a spike in errors, a surge in traffic to an admin route, a jump in paid-API spend.

9. Make it a habit

The single highest-leverage move is turning all of the above from a one-time heroic cleanup into a recurring cadence. A short weekly pass (audit dependencies, scan for secrets, review whatever changed that week) plus a fuller review each month will catch the overwhelming majority of what matters. Keep a short log of each run so "security" becomes something you can show a partner, not just something you claim.

The enterprise-and-compliance angle

If selling to bigger customers is anywhere on your horizon, a little groundwork pays for itself fast:

  • Keep a one-page security overview you can hand to a prospect: how you handle auth, encryption, backups, dependencies, and incident response.
  • Start a lightweight risk log and an incident-response plan now, while they can fit on a page. They're much harder to write under pressure.
  • When you're ready, frameworks like SOC 2 or ISO 27001 formalize this. You don't need them on day one, but knowing they exist shapes good habits early, and most of their controls are just this checklist with paperwork.

LLM prompts that actually help

A capable coding model is a genuinely useful security reviewer for a small team, not a replacement for expertise, but a tireless second set of eyes. The trick is to point it at concrete artifacts and ask for evidence, not vibes. A few prompts I reuse:

Audit your own endpoints for missing authorization:

Review every server-side API route in this project. For each one that changes
data or exposes admin/internal functionality, tell me whether it verifies the
user's session AND their role on the server. Flag any route that relies only on
a page-level or client-side guard, or that trusts a user id/role from the
request body. Show the file, the line, and the exact code that proves the gap.

Hunt for injection and XSS from untrusted input:

Treat all user input, uploaded files, URLs, and third-party/scraped content as
attacker-controlled. Find (1) database queries built by string concatenation
instead of parameters, (2) places that render untrusted content as raw HTML
without a real sanitizer, (3) shell commands built from input, and (4) links or
fetches using an unvalidated URL. For each, give the file, line, a concrete
exploit input, and the minimal fix.

Review a dependency before you add it:

I'm considering adding <package> to a small production app. Summarize its
maintenance health (maintainers, release cadence, open critical issues), how
many transitive dependencies it adds, its known CVEs, and whether a lighter or
better-maintained alternative exists. Recommend for or against, with reasoning.

Draft the security answers enterprise buyers ask for:

Act as a security engineer helping a solo founder answer a vendor security
questionnaire. Based on this description of my stack and practices [paste],
draft honest answers about authentication, authorization, encryption in transit
and at rest, secret management, dependency management, logging, backups, and
incident response. Flag any question where my current answer would be a red flag
to an enterprise buyer, and tell me the smallest change that would fix it.

Turn a finding into a fix and a regression test:

Here is a security finding: [paste]. Propose the smallest safe fix that matches
this codebase's existing patterns, explain why it closes the issue, and write a
test that fails on the vulnerable version and passes on the fixed one.

One caution: never paste real secrets, customer data, or production credentials into a prompt. Redact first. The goal is a smarter review, not a new leak.

The whole thing in one breath

You're not too small to be attacked; you're too small to recover easily, which is exactly why the cheap, boring, known fixes are worth more to you than to anyone. Lock every door on its own, and treat every input as hostile. Keep your dependencies and secrets clean. Then make the checking a weekly habit instead of a someday project. That's most of security for most small teams, and it's entirely within reach of one person with a checklist and a good set of prompts.