Quick Answer:
Authentication verifies who you are; authorization verifies what you have access to. Getting the second wrong lets one customer see another customer's account — a pattern OWASP calls Broken Access Control and lists as the #1 vulnerability in the OWASP Top 10 2021. For a small business, that translates into leaked data, fines, and lost trust.
Key Takeaways:
- Two distinct questions: Auth0 explains that authentication verifies who a user is and authorization verifies what they have access to — separate processes that most business owners conflate.
- Broken Access Control is #1: in the OWASP Top 10 2021, Broken Access Control leads the list, including the IDOR pattern that lets a user view or edit someone else's account by changing an identifier in the URL.
- 2FA is what experts do: NIST cites a Google survey finding that using 2FA is among the top three things security experts do to protect themselves online.
- Password reuse is massive: NIST cites a TeleSign statistic that 54% of consumers use five or fewer passwords for all of their accounts — one breach compromises five services.
- JWT + RLS is the modern pattern: the Supabase documentation shows how a signed JWT plus Row Level Security restricts database access at the individual row level, without writing permission logic at every endpoint.
If you sell online, take reservations, manage patient records, or simply have an admin panel where your team edits orders, there are two questions your platform should answer well before doing anything else. The first is "who are you?" and the second is "what are you allowed to see?" Most business owners we work with in Houston, Cypress, Monterrey, and Bogotá never separate those two questions — and that is exactly where the most expensive data leaks are born.
This article translates the technical concepts into business-owner language: what they mean, the real-world failure patterns we see in small business sites, and what you should demand from your developer, agency, or SaaS platform. Citations are to sources you can read yourself: OWASP, NIST, Auth0, and Supabase.
Authentication vs. Authorization: the distinction that matters
According to the Auth0 documentation, authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to. Auth0 adds that authentication is usually done before authorization, and authorization is usually done after successful authentication. That sounds obvious, but the practical business implication is large: even if your customer logged in correctly with their password (authentication succeeded), that does not mean they have permission to open any order they want (authorization).
Auth0 sums it up with a principle worth printing and taping above your developer's desk: access to a resource is protected by both authentication and authorization. If you cannot prove your identity, you will not be allowed into a resource. And even if you can prove your identity, if you are not authorized for that resource, you will still be denied access.
Practical analogy: authentication is showing your ID at the lobby. Authorization is the keycard that only opens the floors you actually work on. Having an ID does not mean you can walk into the finance floor.
The OWASP Top 10 and why it matters to you
OWASP is the reference foundation for web application security. Its Top 10 list is what the industry uses to prioritize risks. In the 2021 edition, according to OWASP's own A01:2021 page, Broken Access Control rose to #1 — displacing injection vulnerabilities, which had topped the list for years.
OWASP defines access control as a mechanism that enforces policy such that users cannot act outside of their intended permissions. When it is broken, OWASP enumerates common vulnerabilities that include: permitting viewing or editing someone else's account by providing its unique identifier — what OWASP calls Insecure Direct Object References (IDOR); bypassing access control checks by modifying the URL (parameter tampering or force browsing); accessing API with missing access controls for POST, PUT and DELETE; elevation of privilege, acting as a user without being logged in or acting as an admin when logged in as a user; and metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT).
IDOR in owner's language:
Your customer Pedro opens his invoice page: yourshop.com/invoice?id=1042. He changes 1042 to 1041 in the address bar — and a different customer's invoice loads, complete with name, address, and total. That is IDOR. No hacker skills required, no tools. It gets discovered by a curious customer at 11 p.m.
Passwords and two-factor authentication (2FA)
Passwords remain the first line of defense — and remain the weakest link. NIST, the U.S. standards institute, defines multi-factor authentication (MFA, sometimes called 2FA) on its Back to Basics page as a security enhancement that allows you to present two pieces of evidence — your credentials — when logging in to an account.
The strongest argument for turning 2FA on is not made by NIST itself. NIST cites a recent Google survey finding that using 2FA is among the top three things security experts do to protect themselves online. In other words: the people who make a living defending systems have it switched on for their own personal accounts. If they consider it essential, your Shopify admin, your business email, and your CRM database access probably need it too.
NIST also cites a TeleSign statistic that illustrates why passwords alone are not enough: 54% of consumers use five or fewer passwords for all of their accounts. And another TeleSign statistic cited by NIST: almost 9 in 10 (86%) say that using 2FA makes them feel like their online information is more secure. That last point matters for your business: offering 2FA to your customers (not just requiring it internally) is a tangible trust signal.
Simple owner decision:
- Turn on 2FA today for your store admin, hosting, domain registrar, and email accounts.
- Require 2FA for every employee with access to customer data or payment systems.
- Prefer authenticator apps (Google Authenticator, Authy) over SMS where the platform supports it — SMS can be intercepted.
- Document the recovery process: when someone loses their phone, you need a protocol that does not break security.
JWTs, sessions, and why your platform talks about tokens
If your developer or SaaS vendor mentions JWTs or tokens, here is the owner version. JWT stands for JSON Web Token: a short-lived, signed credential your browser presents to the server after logging in, on every request. The Supabase documentation, used by many modern applications, states that Supabase Auth uses JSON Web Tokens (JWTs) for authentication.
Supabase also describes how the integration works: Auth integrates with Supabase's database features, making it easy to use Row Level Security (RLS) for authorization. In owner's terms: the system signs a token when you log in, and that token carries your identity verifiably down to the database, where RLS rules decide exactly which rows (which orders, which patients, which clients) you may see. Supabase further notes that Auth uses the project's Postgres database under the hood, storing user data and other Auth information in a special schema — which is how identity ties to your application tables through triggers and references.
The related risk: OWASP enumerates metadata manipulation, such as replaying or tampering with a JSON Web Token, among the Broken Access Control patterns. If your platform does not validate the JWT properly on the server — for example, if it accepts a client-side altered token — an attacker can forge their identity. That is your developer's or SaaS platform's responsibility, but as the owner you should ask: how do you validate the JWT? Do you use a standard library or did you write it by hand?
The three real-world leak patterns in small business sites
Of the failures OWASP lists under Broken Access Control, three are the ones we see repeatedly on small business sites:
1. IDOR on account or invoice pages. The customer changes a number in the URL and sees another customer's data. OWASP describes it as permitting viewing or editing someone else's account by providing its unique identifier. Root cause: the server trusts the ID in the URL instead of checking whether the current user actually owns that ID.
2. APIs without write-side access control. OWASP explicitly mentions accessing API with missing access controls for POST, PUT and DELETE. Owner version: your platform protects the admin page well (no one can log in without credentials), but the internal endpoints that update products or delete customers can be called directly without a valid session if someone finds the URL.
3. Privilege elevation. OWASP defines it as acting as a user without being logged in or acting as an admin when logged in as a user. In practice: the difference between a normal user and an administrator is decided by a field in the JWT or session, and that field is not properly validated server-side.
"Most owners think the security risk is a hacker in a hoodie. The real risk is a bored customer who changes a number in the URL and discovers your system trusts too much."
- Diego Medina F, Founder of MerchandisePROS
What this means for your business
Authentication and permissions are not topics to delegate blindly to the IT team and forget. They are business decisions: how much customer data you store, who on your team can see it, what happens when an employee leaves, and how you demonstrate to customers and regulators that you take the topic seriously. Our Website Consulting service reviews this exact perimeter as part of the UI/UX and digital presence audit: 2FA availability on the admin, IDOR risk on account pages, form validation, error-page exposure, and permission discipline on your current platform (Shopify, WordPress, Wix, custom). We deliver a prioritized report with what to fix first and what can wait — not a context-free automated scan.
If you only have 60 seconds, start with the Free Audit: it gives you a 0–100 score across basic security, AEO, speed, and conversion, with the specific points that are open. If you want to go straight to a conversation, book a 30-minute call and we will review your platform live.
Frequently Asked Questions
What is the difference between authentication and authorization?
Auth0 puts it directly: authentication verifies who a user is, while authorization verifies what a user has access to. Authentication usually happens first (with a password, one-time code, or biometric); authorization happens after and decides which data or actions are allowed.
What is IDOR and why should a small business care?
IDOR (Insecure Direct Object Reference) is an access control failure where a user can view or edit another user's account simply by changing an identifier in the URL. OWASP lists it among the most common patterns of Broken Access Control, the #1 vulnerability in the OWASP Top 10 2021.
Is 2FA really necessary for a small business?
Yes. NIST cites a Google survey finding that using 2FA is among the top three things security experts do to protect themselves online. For a store, admin panel, or CRM, turning 2FA on is the cheapest, highest-impact security upgrade available.
What is a JWT and why does my platform mention it?
A JWT (JSON Web Token) is the short-lived, signed credential your browser presents after logging in. The Supabase documentation states that Supabase Auth uses JWTs for authentication. If an attacker tampers with a JWT, OWASP lists this as an access control failure via metadata manipulation.
What do you audit when you review a site's login security?
We check whether 2FA is available for admins, whether account pages are at risk of IDOR, whether forms use HTTPS, whether customer data is gated by row-level access control, and whether error pages leak information. We deliver a prioritized report — not a context-free automated scan.