Security

Security baked in, not bolted on.

Most agencies treat security as a checkbox they tick before launch. We treat it as a design constraint from the first commit. That difference shows up in every layer of every site we ship - and it's why a small studio can defend a small business as carefully as the team that defended your bank.

What you're actually worried about

Four things you trust us with. Each is its own discipline.

Your data

Customer info, lead submissions, account credentials. Hashed at rest, validated at the door, never exposed to the browser.

Your money

Every invoice generated in QuickBooks; payments are processed by Intuit Payments. Your site never touches a card number, which keeps you out of PCI compliance scope entirely.

Your site

Hosted on enterprise infrastructure with automatic HTTPS, edge DDoS protection, and rate-limited public endpoints that quietly absorb bot traffic.

Your access

Admin routes gated by role, login rate-limited, self-lockout impossible by design. Every change to a customer record is timestamped.

How we actually do it

Five layers. Every one mandatory.

01 / AUTH

Accounts & sessions you can trust.

Passwords hashed with bcrypt - never stored in plaintext, never recoverable.
Session tokens signed with JOSE (JWT). Tampering invalidates the session.
New accounts held in Pending until an owner approves them - no random signups gain access.
Forgot-password flow uses time-limited reset tokens, scoped to a single user.
Customers cannot reach admin routes - middleware rejects the request before any code runs.

02 / API

Forms and inputs, validated before they touch the database.

Every API endpoint validates payloads with Zod schemas. Malformed or oversized data is rejected at the door.
Every database query is parameterized via tagged template literals. SQL injection is structurally impossible.
Public endpoints (contact, login, signup) are rate-limited per IP. Brute-force and flood attempts fail silently.
Hidden honeypot fields catch automated spam invisibly - real visitors never see them.
React's default output escaping prevents script injection (XSS) from anything a user types.

03 / PAY

Payments handled by people who do nothing else.

All cards are processed on QuickBooks's hosted invoice page. Your site never sees the number, the CVV, or the expiry.
Every QuickBooks webhook is HMAC-verified server-side. An attacker hitting your webhook URL cannot forge a paid event.
Prices are computed server-side from the catalog. A visitor cannot edit JavaScript and pay $1 for a $1,500 package.
Refunds, disputes, and chargebacks flow through Intuit's audited pipeline - and every transaction lands directly in your books, so reconciliation happens automatically.

04 / INFRA

Hosting and secrets, kept far away from the browser.

Deployed on Vercel's edge network: automatic TLS, certificate renewal, and DDoS absorption with zero configuration.
API keys, database credentials, and signing secrets live in environment variables - never in source, never in the repo, never sent to the client.
Next.js server components keep sensitive logic (queries, third-party calls, business rules) off the browser entirely.
No WordPress, no plugins, no shared template codebase. A vulnerability in someone else's site cannot reach yours.

05 / OPS

Admin actions, audited and reversible.

Every admin route re-checks role and status server-side. A stale browser tab cannot grant access after a permission change.
Login attempts are rate-limited and password complexity enforced on the API, not just the form.
You cannot accidentally suspend, demote, or delete your own owner account - the UI and the API both refuse.
Every record has created_at and updated_at timestamps. You always know who changed what and when.

Categories that don't apply to you

Whole risks that never reach your business because of how the site is built.

Eliminated

Plugin attack surface

No third-party plugin codebase. The category of vulnerability that takes down WordPress sites every week doesn't apply here.

Eliminated

PCI compliance scope

Your business never stores or transmits card data. The compliance burden lives entirely with Intuit Payments.

Eliminated

Secrets in source

Nothing sensitive sits in the repo, in commit history, or in client-side JavaScript. Rotating a key takes one minute, not a panic.

holmor.security.audit

passing

$ holmor security audit

> running 9 checks...

✓initialized

✓ passwords : bcrypt (hashed, salted)

✓ sessions : JOSE / signed JWT

✓ database : parameterized queries

✓ payments : Intuit Payments (PCI offloaded)

✓ secrets : env vars only

✓ tls : auto (Vercel-managed)

✓ rate_limit : enabled, per-IP

✓ honeypot : enabled, silent block

✓ admin_gate : server-side role check

> all checks passed (9/9)

> clean. ready to ship.

passing9 / 9last run · on every deploy

audit

Who's behind the work

The same standards that defended your bank.

Our lead engineer, Aaron Morris, spent eight-plus years building and hardening software for Fortune 500 companies across fintech, utilities, and cybersecurity. The standards he applied to regulated, high-stakes systems are the same ones running on your site.

A vulnerability in your codebase wouldn't just be your problem - it would land on the desk of someone who's already responded to that class of incident at scale. The practical result is that we tend to flag things during the build that other shops only learn about after a breach.

8+ yr

Fortune 500 build & defend

Plaintext secrets

9 / 9

Checks on every deploy

Audit your current site

Want to know where you're exposed?

A Security & Hardening Audit covers headers, dependencies, authentication, secrets, and the common pitfalls that take down small-business sites. Run by Aaron. Clear written report. No fluff, no upsell.

Request an AuditAdd it to a Build