Quick Answer:
Row-Level Security (RLS) is the rule inside your database that ensures each user can only see their own records. Without RLS, a single code bug can expose every customer's information. It is the layer that separates a professional site from one that is a single bug away from a mass data leak.
Key Takeaways:
- RLS acts like an automatic WHERE clause: according to Supabase documentation, RLS policies work as if a WHERE clause were added to every query, filtering data inside the database engine itself.
- OWASP Top 10 is the global standard: OWASP describes its Top 10 as a standard awareness document for developers and web application security.
- GDPR applies outside Europe: according to GDPR.eu, the law applies even if your business is not located in the EU, as long as you process data on EU citizens or residents.
- Fines are corporate, not symbolic: up to 20 million euros or 4% of global annual revenue, whichever is higher, per the official GDPR text.
- NIST CSF 2.0 is the operational guide: finalized in 2024 by NIST, it helps organizations understand and manage cybersecurity risk in a structured way.
If you run a website that captures email addresses, processes orders, manages customer accounts, or stores any personal data, you already operate a system with legal and reputational responsibility. It does not matter whether your business is in Houston, Cypress, Monterrey, or Bogotá: the rules that protect your customers' data are the same, and so are the consequences of ignoring them.
This article translates the technical jargon into the only thing that matters to a business owner: what to ask, what to demand, and how to recognize when your technology vendor is exposing you to a serious problem.
What RLS is, and why it matters more than you think
Row-Level Security is a feature of modern databases that decides which rows each user is allowed to read. The rule is applied inside the database engine, not in the application code. That distinction is what makes it so powerful.
According to the official Supabase documentation, RLS policies work as if a WHERE clause were automatically added to every query. A typical example reads: "User can see their own profile only," with a policy that filters by the authenticated user's ID. If a developer forgets to put that filter into a query, RLS applies it anyway. It is a safety net at the last possible layer, before any data leaves the database.
That same documentation calls this pattern defense in depth: even if another control fails, RLS is still there. And it emphasizes that once RLS is enabled on a table, no data is accessible through the API until explicit policies are created. In other words: by default, everything is closed. That is the opposite of the usual approach in small sites, where everything is open by default and security is "added later" (almost always too late).
What happens without RLS:
Any mistake in the application code (a missing filter, an unvalidated URL parameter, an unauthenticated endpoint) leaves the database fully exposed. Customer A can read Customer B's data by simply changing a number in a URL. This is not theoretical — it is the real mechanism behind most of the breaches that end up in the headlines.
OWASP Top 10: the risk map every vendor should know
OWASP (Open Worldwide Application Security Project) describes its Top 10 as "a standard awareness document for developers and web application security." It is the reference list, updated periodically, of the most critical risks to web applications. The current version is OWASP Top 10 2025.
As a business owner, you do not need to memorize the list. But you do need to know it exists, and to ask one simple question to whoever builds or maintains your site: "How do you address the OWASP Top 10 risks?" The answer should be concrete. If the vendor does not recognize the name, you already have the most important answer: your site is not being built against a globally recognized security framework.
Recurring categories in every edition of OWASP Top 10 include broken access control, cryptographic failures, and injection vulnerabilities. RLS is precisely one of the controls that mitigates the number-one risk: broken access control. That is why it is worth knowing your team can name it.
Encryption: TLS, at-rest, and hashed passwords
Encryption means transforming data so that only someone with the right key can read it. There are three places where your site needs real encryption, not cosmetic:
- In transit (TLS / HTTPS): when a customer's browser sends an email address or a password to your server, that traffic must be encrypted. The padlock in the browser is the visible signal. If your site still shows "not secure" in Chrome, that is urgency number one.
- At rest: the disks where the database stores information must also be encrypted. Modern services enable this by default, but it has to be verified.
- Passwords: never in plain text. Passwords are stored as a hash, an irreversible cryptographic fingerprint. If your vendor "can remind you" of your current password, that is an immediate red flag: it means they store it in a recoverable form, which is unacceptable.
GDPR and LFPDPPP: why they apply even outside Europe
GDPR (the General Data Protection Regulation) is, according to GDPR.eu, "the toughest privacy and security law in the world." It took effect on May 25, 2018. The part that surprises most business owners in the United States and Latin America is its scope:
"If you process the personal data of EU citizens or residents, or you offer goods or services to such people, then the GDPR applies to you even if you're not in the EU."
— GDPR.eu
Maximum fines, per the same text, reach 20 million euros or 4% of global annual revenue, whichever is higher. For a small business this may sound far away, but the principle matters: personal data has rules, and those rules carry real economic consequences.
In Mexico the equivalent law is LFPDPPP (Federal Law on the Protection of Personal Data Held by Private Parties). It shares the same fundamental principles as GDPR: consent, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, and demonstrable accountability. If you comply well with one, you are very close to complying with the other.
The seven principles GDPR.eu lists for handling personal data are a good operational checklist for any business: lawfulness, purpose limitation, minimization, accuracy, storage limitation, integrity and confidentiality, and accountability.
NIST Cybersecurity Framework 2.0: the operational guide
The NIST Cybersecurity Framework is, in NIST's own words, a guide designed to "help organizations to better understand and improve their management of cybersecurity risk." The current version is CSF 2.0, finalized in 2024.
Although NIST targets organizations of any size, its practical value for a small business lies in its structure: identify your assets, protect them, detect incidents, respond, and recover. For a business owner, that sequence is exactly what your technology vendor should be able to walk you through when you ask "what happens if we get attacked?"
The 3 signs your vendor is not taking security seriously
Red flag 1: they cannot explain how data is protected at the database level.
If the only answer is "the code has validations," a layer is missing. You need to hear words like RLS, access policies, role separation, or equivalents.
Red flag 2: they do not mention OWASP or NIST when you ask.
These are the two most widely recognized frameworks in the world for web applications and cybersecurity. A serious vendor knows them. A vendor who is improvising, does not.
Red flag 3: they have no written backup or incident response policy.
"We do backups" is not a policy. A policy specifies how often, where they are stored, how they are tested, and what happens the day the database is corrupted or hit with ransomware.
What this means for your business
Most data breaches at small and mid-sized businesses are not sophisticated attacks. They are configuration mistakes: a database without RLS, an unauthenticated endpoint, a public cloud backup, a password stored in plain text. All preventable, all invisible to the owner until it is too late.
MerchandisePROS's Website Consulting service is exactly the audit that closes that blind spot. We review your site from the perspective of UI/UX, Core Web Vitals, and security: we validate that your vendor is applying the right controls, we translate their work into a report you can actually understand, and we hand you the precise questions to ask them in your next meeting. We do not replace your developer: we audit them, we guide them, and we make sure your business is not the next headline.
"Business owners do not need to learn to code. They need to learn to ask the three right questions. That is all that separates a secure company from a vulnerable one."
- Diego Medina F, Founder of MerchandisePROS
Frequently Asked Questions
What is Row-Level Security (RLS) in plain terms?
RLS is a database-level rule that limits which rows each user can read. According to the Supabase documentation, RLS policies work as if a WHERE clause were added to every query, so a user only sees the records that belong to them.
Does my small business need to comply with GDPR?
Yes, if you process the personal data of EU citizens or residents. According to GDPR.eu, the law applies even if your business is not in the EU. Maximum fines are up to 20 million euros or 4% of global annual revenue, whichever is higher.
What is the OWASP Top 10?
OWASP describes its Top 10 as a standard awareness document for developers and web application security. It lists the most critical risks to web applications and is the most widely used reference among serious development teams worldwide.
What are the 3 signs my vendor is not taking security seriously?
Three clear signs: they cannot explain how data is protected at the database level, they do not mention OWASP or NIST when you ask, and they have no written backup or incident response policy. Any one of the three is reason enough to get a second opinion.
What is NIST and why does it matter for my business?
The NIST Cybersecurity Framework (version 2.0, finalized in 2024) is a set of guidelines designed to help organizations understand and manage cybersecurity risk. NIST describes it as guidance "for industry, government, and organizations to reduce cybersecurity risks."