Server-side authorization
Protected reads and writes are checked behind the interface. Roles and allowed actions are planned around the actual users.
Security-conscious engineering / matched to the product
Security belongs
in the architecture.
The interface should look trustworthy. The system behind it should enforce trust through real access, data, and production boundaries.
Built into the work
Protection follows the request.
A hidden button is not authorization. A hosted database is not automatically isolated. A CDN is not automatically an origin lock. The implementation is what matters.
Data boundaries
Queries are limited to permitted records. Database policies such as row-level security are added only where the selected data model benefits from them—and then tested with allowed and denied cases.
Secrets stay behind the server
Private API keys and service credentials are kept out of browser code, public repositories, page source, and user-visible responses.
Input and abuse controls
Forms and APIs use validation, size limits, safe output handling, and rate or bot controls appropriate to the traffic and risk. Legitimate search discovery stays crawlable while abusive automation and scraping can be restricted at the edge and application layer.
Transport and browser safeguards
Production launches verify HTTPS, certificates, redirects, important browser headers, and the path between the public edge and the application.
Operational ownership
Accounts, monitoring, backups, restore expectations, temporary access, maintenance, and handoff are recorded instead of assumed.
Matched to the product
A brochure site and a private platform should not receive the same security plan.
Minimize the attack surface, validate enquiry routes, protect server secrets, use HTTPS, and keep ownership clear.
Add server-side identity and permission checks, database access boundaries, session protection, audit needs, backups, monitoring, and denied-path tests.
Start with a separate risk and compliance review. Specialist testing or legal guidance is added when the written scope requires it.
Tools are not the control by themselves
Configured, enforced, tested.
Cloudflare, Clerk, Firebase, Supabase, PostgreSQL, and similar services can support a strong system. None of them makes an application secure simply by being present.
CDN, bot, and firewall services help only when traffic cannot quietly bypass the intended path.
Sign-in is useful only when every protected server operation enforces the authenticated identity and permissions.
Security rules or row policies need least-privilege credentials, correct context, and cross-user isolation tests.
Validation, output handling, dependency maintenance, error behavior, and operational access still matter around every vendor.
Technical control index
A useful control has a job, an owner, and a test.
Not every project needs every item below. The written scope selects the controls that match the data, users, integrations, and failure cost.
TLS, HTTP Strict Transport Security, Content Security Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, secure cookies, output encoding, and cross-site scripting defenses.
Server-side schema validation, CORS allowlists, CSRF protection where applicable, rate limiting, bot and honeypot controls, safe file handling, parameterized queries, and SSRF protections.
Authentication, role-based access control, ownership checks, tenant isolation, least privilege, database constraints, and PostgreSQL row-level security only where the selected architecture uses and tests it.
Secret and dependency scanning, safe error responses, audit logs, monitoring, backup schedules, restore expectations, migration records, and documented incident contacts.
Cloudflare proxying, WAF and bot controls when included, strict TLS, DNS review, and origin locking through a tunnel or firewall rules where the hosting design supports it.
Logged-out URL reuse, expired sessions, direct API calls, changed record IDs, cross-user reads and writes, role changes, malformed payloads, and rate-limit behavior are tested on authorized systems.
Quiet failure review
Ten controls that should not be left to generated boilerplate.
These are reviewed when the architecture makes them relevant. A proposal names which controls apply, and the finished system describes them as delivered only after configuration and verification.
Privileged database functions receive explicit search paths and execution grants; they are not treated as shortcuts around tenant isolation.
Authenticated pages and private API responses use no-store or private cache directives so one user’s data cannot become shared edge content.
Old records, exposed origin addresses, and abandoned subdomains are reviewed; proxying is paired with a tunnel or firewall boundary when the hosting design supports it.
Automation dependencies are pinned to reviewed immutable revisions where available, and production builds run dependency and secret checks.
Signed webhooks also enforce timestamp tolerance and idempotent event handling so an old valid request cannot be replayed as a new action.
Private server code and secrets never ship to the browser. Production source maps are disabled or intentionally access-controlled when they would reveal non-public implementation detail.
External browser code is minimized. Stable third-party assets use integrity checks or self-hosting when practical; dynamic vendors receive a narrow content policy and consent boundary.
Opaque identifiers reduce easy enumeration, but authorization still checks the signed-in user, role, tenant, and record ownership on every protected request.
Passwords, session tokens, API keys, payment data, and authorization headers are excluded or redacted before application and infrastructure logs are retained.
Administrative access uses least privilege, short-lived sessions, audit history, and multi-factor authentication when a privileged admin surface is part of the delivered system.
The security questions
Start with what can go wrong.
A product earns a stronger foundation by answering four concrete questions before launch, not by collecting vendor logos.
- 01
Who can do what?
Name every user type, protected action, administrative path, and ownership boundary.
- 02
What data matters?
Classify the records, retention, privacy obligations, secrets, uploads, and third-party transfers.
- 03
How could it be abused?
Model direct API access, changed IDs, session reuse, automation, malicious input, origin bypass, and service failure.
- 04
What proves the boundary?
Record allowed and denied tests, production headers, backup ownership, health checks, and unresolved risks.
A clear handoff
Own the important accounts.
- Domain and DNS stay client-controlled.
- Analytics, Search Console, and Workspace use client-owned accounts when included.
- Temporary studio access is reduced or removed as agreed.
- Source, deployment, support, and data responsibilities are documented.
- No website is described as unhackable, and no ranking or uptime result is guaranteed.
Start with the real risk