Treating security as a feature means building it into the product's default behavior, so every customer is protected without buying an add-on or ticking a box on a compliance form. On a platform that hosts many websites and online stores, that starts with one promise: one customer's data can never reach another customer. Everything else, from sign-in to backups, is built on top of that.
This article explains what "security as a feature" means in practice, which controls matter most for a hosted site or store, and the questions worth asking any platform before you trust it with your business.
Why a checkbox is not enough
Compliance checklists are useful, but they describe a minimum at a point in time. Attackers do not work from the checklist. The numbers show why that gap matters.
- IBM's Cost of a Data Breach Report 2026 puts the global average cost of a breach at $4.99 million, a 12% increase on the previous year and a record high.
- Verizon's 2026 Data Breach Investigations Report, published in May 2026, found that 31% of breaches started with exploitation of a vulnerability. It was the first time in the report's 19 years that this overtook stolen credentials as the top way in.
- The same report found that breaches involving a third party jumped 60% and now make up 48% of the total. Your platform, your apps and your agencies are part of your attack surface.
For a business running on someone else's platform, those figures carry a clear message: the security of the platform is your security. It is not a line item; it is part of what you are buying.
Isolation is the product
A multi-tenant platform serves many customers from shared infrastructure. That is what makes it efficient, and it is also where the most serious risk sits. If one store can read another store's orders or customer records, no other feature matters.
The OWASP Top 10, the most widely used list of web application risks, ranks Broken Access Control first in its 2025 edition. OWASP reports that 100% of the applications it tested had some form of broken access control, with more than 1.8 million recorded occurrences. Its prevention advice is direct: deny by default, and enforce record ownership rather than letting users create, read, update or delete any record.
Enforce it in the database, not only in code
Application code checks permissions on every request, and most of the time it gets them right. "Most of the time" is the problem. A better design enforces isolation at a lower layer as well, so a single mistake in application code does not become a data leak.
PostgreSQL's row-level security is one well-known way to do this. Once enabled on a table, policies decide which rows a query can see or change, and if no policy exists, the documentation says a default-deny policy applies: no rows are visible or can be modified. The documentation also notes that superusers and table owners normally bypass these policies unless the table is set to force them, which is exactly the kind of detail worth asking a vendor about.
Deny by default
The safest system is one where access has to be granted, not one where it has to be remembered to be taken away. Applied to a platform, that means new tables, new endpoints and new staff accounts start with no access and gain only what they need.
Layers, from the visitor to the database
No single control stops everything. A sound platform places a separate line of defense at each layer, so an attack that gets past one meets the next.
At the edge
A web application firewall and bot filtering can stop malicious or abusive traffic before it reaches a server. That protects availability as well as data: automated scraping and credential-stuffing bots cost money and slow a store down even when they fail.
In the browser
A Content Security Policy tells the browser which scripts and resources a page is allowed to load. MDN describes it as mainly a defense against cross-site scripting. Its reporting feature sends violation reports to an endpoint, so you learn when something tries to run that should not. For a store, where a single injected script on a checkout page can skim card data, this matters.
At sign-in
Most damage from a compromised account comes from what that account can do. Three controls limit it:
- Two-step verification, so a stolen password alone is not enough.
- Roles and permissions, so an editor cannot change payment settings and a contractor sees only what their job needs.
- An activity log, so you can see who changed what, and when.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) makes the same point in its Secure by Design guidance: security should be a core business requirement, and features such as multi-factor authentication, logging and single sign-on should be available at no extra cost.
For secrets
API keys, payment credentials and database passwords should never sit in code or configuration files. A managed secrets vault keeps them out of the codebase, limits who can read them, and makes rotation routine instead of an emergency.
For recovery
Security also means getting back to a good state when something goes wrong, whether the cause is an attacker, a bad import or a mistaken bulk edit. Backups are only as good as your ability to restore them with confidence, so look for point-in-time recovery and a way to preview a backup before restoring it.
Security that ships by default
A useful test for any platform: which of these protections are on for every customer from day one, and which are extras? When isolation, two-step verification, audit logs and backups are standard, every site benefits, including the small ones that would never have bought an upgrade. That is what "security as a feature" means in practice.
Default security also lowers the burden on your team. You should not need a security engineer to switch on protections the platform could have enabled for you.
Questions to ask any platform
- How is my data separated from other customers' data, and at which layer is that enforced?
- Is access denied by default, and how are staff and admin permissions controlled?
- Is two-step verification available to my whole team, and is there an activity log?
- Where is my data hosted, and where are secrets such as API keys stored?
- What does recovery look like: can I restore to an earlier point in time, and preview a backup first?
- Which security features cost extra?
How CIQRA approaches it
On CIQRA, each site's data is isolated from every other site at database level, and secrets are held in Azure Key Vault and rotated regularly. Teams sign in with two-step verification, with roles and permissions and an activity log of who changed what. A web application firewall and bot filters stop bad traffic before it reaches a server, and a Content Security Policy lets only approved scripts run and reports attempted attacks. Data is hosted in Microsoft Azure data centers in Germany. Site backups are built in, and you can preview a backup before restoring it or recover the database to an earlier point in time.
FAQ
What does "security as a feature" mean?
It means security is built into the product's defaults rather than sold as an add-on or treated as a compliance exercise. Every customer gets the core protections without asking for them.
What is tenant isolation?
On a platform that serves many customers from shared infrastructure, tenant isolation guarantees that one customer's data cannot be read or changed by another. The strongest designs enforce it in the database as well as in application code.
Is a compliance certificate the same as being secure?
No. A certificate shows that controls existed when they were assessed. Security as a feature means those controls are part of the product and are kept in place continuously.
Sources
- IBM, Cost of a Data Breach Report 2026, 2026
- Verizon, 2026 Data Breach Investigations Report news release, 2026
- OWASP, A01:2025 Broken Access Control, 2025
- PostgreSQL Global Development Group, Row Security Policies (documentation), 2026
- MDN Web Docs, Content Security Policy (CSP), 2026
- CISA, Secure by Design, 2026