Security standards and protocols for clients and website blog

When consulting with businesses about building a custom web application, the number one concern we hear is always the same: 

"Is my data, and my customers' data, going to be safe?" 

It is a valid fear. In today's digital landscape, a security breach can break your app, and your reputation too. At our company, we don't treat security as an afterthought or a "nice-to-have" feature added at the end; it’s the very foundation of how we build. This document explains how we approach building web applications securely and the steps we take to prevent hacking.

If you’re not a software engineer, don’t worry. This was written in plain English so anyone can understand it.

How we structure every application

One of the most common mistakes made when building web applications today is treating the entire application as a single, monolithic unit.

Why "vibe coding" is a security risk

"Vibe coding" can feel like the most accessible way to build. You describe what you want and get an app quickly. But done the wrong way, you end up with something you didn't really build and can't really fix, locked into a single all-in-one platform. This will leave you crossing your fingers and hoping it doesn’t break. While vibe coding might work for a simple landing page, it is a recipe for disaster for a complex, data-driven application.

We see it often: a developer builds everything on one all-in-one platform, connects a payment gateway by pasting a secret key directly into the code, and deploys without a security review. This opens the door to:

• Exposed secret keys: Payment credentials (like Stripe keys) visible in the source code can be stolen by anyone who views the page and could be used to make charges to your account.
• Unprotected databases: Tables with no access rules mean any user, or any hacker, could read or delete all of your data.
• No rate limiting: A bot can flood your login page with thousands of password guesses per second until one lands.
• No input sanitisation: An attacker can type a malicious command into a form field and run code directly on your database.
• Single platform with no redundancy: Everything lives in one place, so one outage or security event takes down your entire application and database at once.

If you want more than a landing page, if you are handling user accounts, payments, or any sensitive data, you should not be building on a single-platform, no-architecture setup.

Our philosophy: The right tool for the right job

We follow a principle called Separation of Concerns: every part of your application is handled by its own purpose-built tool, and those tools talk to each other through secure connections:

1. For the frontend (This is what your users see): We use robust frameworks like React and Next.js. These ensure your app is lightning-fast, highly responsive, and structurally sound.
2. For the Hosting (Where your app lives): We rely on enterprise-grade cloud providers like Vercel or Webflow Cloud(Cloudflare) to guarantee maximum uptime and secure infrastructure.
3. For the Backend (Your database and logic): We utilize dedicated, highly secure backend platforms like Supabase, Xano, or Convex.

Each layer is isolated, so if one part is ever attacked or compromised, the damage can't spread to the rest. Think of it like a hotel: your key card opens your room and nothing else. Someone stealing one key doesn't get the master key to the building.

Protecting your data: Database security

Your database is the most sensitive part of your application. It holds customer information, business transactions, personal records, and more. We treat database security as a non-negotiable standard.

How we structure database access

Not everyone in a system needs access to everything. A customer should only be able to see their own data, while a support agent should not be able to delete records. We enforce this using an Access Control Matrix.

Row-level security (RLS)

Beyond role-based access, we use a database-level technique called Row-Level Security. This limits users to only the rows that belong to them, even at the database query level. 

If there were a bug in the application code, the database itself would refuse to return data that the requesting user does not own. For example, if a customer requests their order history, the database will automatically filter out every other customer's orders.

Environment variables and secret management 

Every application has secret keys: PI keys, payment credentials, database passwords, third-party service tokens. These must never be placed in the frontend code, and must never be committed to a code repository.

We store all secrets in environment variables on the server side, using platform-level secret managers. This means:

• No secret key is ever visible in the browser or in the application's source code.
• Payment gateway credentials (Stripe, Polar, etc.) only ever exist on the backend server. The frontend only ever receives a secure token in return.
• Database credentials are stored in encrypted environment vaults, not in plain text anywhere.

Authentication 

Passwords are never stored in plain text. We hash them with industry-standard algorithms, so even if someone accessed the database, every password would be an unreadable string of meaningless characters that can't be reversed.

Rate limiting

Rate limiting means setting a maximum number of requests that can be made to any endpoint within a given time period. Implementing protects you from getting flooded with password guesses, contact and sign up form spamming, and requests overloading your server until it crashes (denial of service attacks).

We implement rate limiting at both the API level and the hosting/infrastructure level, ensuring that abusive traffic is blocked before it ever reaches your application's core logic.

Input sanitisation and validation

Every form field, every search box, every piece of text that a user can type into your application is a potential attack vector. The most common attack that exploits this is called SQL Injection, where an attacker types a database command into a form field, hoping the application will execute it as a real database query.

We prevent this by:

• Validating all inputs: Checking that data matches the expected format (e.g. an email field only accepts valid email addresses, a phone number field only accepts digits).
• Sanitising all inputs: Stripping out any characters or code patterns that could be interpreted as commands before the data reaches the database.
• Using parameterised queries: A database programming technique that treats user input as data only, never as executable code, regardless of what the user types.
• Server-side validation: Even if client-side (browser) validation is bypassed, server-side checks catch everything before it reaches the database.

Hosting security 

We use purpose-built, enterprise-grade hosting platforms that handle a significant portion of infrastructure security by design.

Vercel and Webflow Cloud

These are the platforms trusted by some of the world's largest companies to serve their websites and applications. Your app inherits enterprise-level protections from day one.

• Global CDN: Your content is served from data centers around the world, so it loads fast for every user and stays resilient against certain denial-of-service attacks.
• DDoS protection: Built-in mitigation stops distributed denial-of-service attacks at the infrastructure level, before they reach your app.
• Automatic security patching: The hosting platform handles infrastructure-level security updates without requiring manual intervention.
• Environment isolation: Each deployment is sandboxed, meaning a compromise of one deployment cannot affect others.

Supabase, Xano, or Convex for the backend

Your backend is where the most sensitive things live, so it deserves the strongest protection. We work with these three platforms to ensure strong protection.

• Dedicated security teams: These platforms employ full-time security engineers who maintain and update security controls continuously.
• SOC 2 compliance: Industry-recognised security certification, meaning their processes and controls are independently audited.
• Encrypted storage: All data stored is encrypted both at rest (when stored) and in transit (when moving between systems).
• Automatic backups: Data is backed up regularly with point-in-time recovery, meaning if something goes wrong, we can restore to a specific moment.
• Audit logs: Every action performed on the database is logged, creating a full trail of who did what and when.

We treat every application as if it will be targeted. Not because we expect the worst, but because being prepared means the worst rarely happens.