Security Is a Process, Not a Milestone
As an organization grows from a handful of services to hundreds or thousands, the way you approach security must change. A periodic penetration test may suffice early on, but that project-based mindset doesn't scale. When you're operating at the scale of serving 220M+ users, the focus has to shift from checking a box to embedding a continuous security mindset into every stage of development.
Wix security experts distilled their experience into ten "security by design" principles for building resilient applications. These aren't theoretical constructs; they're hardened practices from one of the largest platforms on the web.
1. Threat Modeling Is a Team Sport
Threat modeling shouldn't be the sole domain of a dedicated security team. Every engineer should understand how data flows through their application and where attackers might try to interfere. When threat modeling happens collaboratively, developers catch design flaws before they become vulnerabilities and build the intuition to spot risky patterns in code reviews.
2. Shift Left—But Not Too Far
Developers should be able to test security issues with static analysis or dependency scanning early in the pipeline, but this isn't an all-or-nothing proposition. Not every check belongs at the IDE level. Some vulnerabilities only become clear when you examine the full application context, such as an insecure API design or a broken authorization chain.
3. Fix the Root Cause, Not the Symptom
When a vulnerability is found, the temptation is to patch the immediate gap. But a lasting practice is to ask how and why that vulnerability was introduced in the first place. Did a framework default need to be overridden manually? Was documentation missing on a security-sensitive API? Add these answers and fixes to your design standards so the same class of bug doesn't recur.
Wix extends this to its dependency management. Every open-source library is cataloged with its version, and security advisories are actively monitored. Not complying with a security policy can break a build or block a release from going out.
4. Context-Aware Logging and Alerts
You cannot react to what you don't know about. It's essential to log authentication attempts, identity changes, and privileged actions across your systems. But log volume alone doesn't produce protection; it's the correlation between events that matters. If a user passes three-factor authentication from one IP and services are immediately called from a different country, the combination should trigger an alert in real time.
5. Policy as Code
Hardcoding authorization rules deep inside a monolithic codebase is brittle when you run a microservices architecture. Declaring security policies in code means the intent is clear, testable, and versioned alongside application changes. Authorization decisions can be made by a centralized service that evaluates identity tokens, so every microservice interprets access the same way.
6. Design for Immutability
A security incident is handled differently when you've built your infrastructure as cattle, not pets. When a web service is compromised, the cleanest path to recovery is to deploy a brand-new container a fresh image, tear down the old session states, and roll out new credentials. This is only fast if your architecture supports disposable environments by default.
7. Safeguard Source and Repositories
Source code gives away more than functionality; it can reveal credentials, internal networking details, and weak points. It is paramount to restrict repository access to the entire development team and jump between production and the source. Where code needs to be referenced in a sandbox or analytics pipeline, it should be sanitized routinely to scrub out any hardcoded keys or certificates.
8. Never Trust User Input
Validation isn't a requirement you can neglect across microservice boundaries. Server-side validation must exist in every layer, not just the front end. Wix uses rate limited APIs for every externally visible endpoint, buckets logins and sign-ups, and combines that with behavior models for detecting brute-force attempts.
9. Defense in Depth for Storage Solutions
Databases are the treasure chest. Security groups should isolate your databases at the network level, and secrets required for privilege escalation should be split. For core DB tools, Wix encrypts at rest and traffic and adds an additional cryptographic layer for any PII or token before it reaches the storage engine.
10. Assume You've Already Been Breached
Perhaps the most important factor in your security culture is to build audited paths and highly monitored environment actions. What will you do more organically than asking "Is this connection legitimately originating in my system?" You also need a well-rehearsed incident response plan in place that defines who goes oncall, what notifications and users see, and how you announce responsibly disclosed incidents without panicking users.
Where to Begin with Your Own Stack
Establishing a fully secure pipeline can't happen overnight, but the tooling to get there is accessible throughout modern development:
- IDE and pre-commit plugins: Surface key issues instantly and often detect hardcoded secrets, SQL injection, or XSS as you are typing or about to commit.
- CI, pre-push hooks, and container scanners: Analyze the deployed artifact, not just the source. Actively inspect components, configs, and dependencies from the registry.
- Regular penetration tests: Don't replace them; still book them periodically as a layer that matters. Bolster that with 24/7 automated secrets inspection.
The most enduring recommendation is to collaborate: define a unified security roadmap so product and security are working toward the same risk model. Where definitions don’t line up, security deadlines slip and your users can feel the gap.
Build Security In From The Start
Waiting until the end of the development cycle to bolt on security is a recipe for disaster. The concept of security by design (SbD) flips that model: you engineer risk out of the system upfront so that mistakes are harder to make. For example, instead of letting developers hand-write SQL strings, you give them a safe Object-Relational Mapping (ORM) layer. Securing the ORM once protects every service that uses it, which shuts the door on SQL injection without adding a review stage to every feature.
The same logic applies to input validation (let the framework check declared types), Cross-Site Request Forgery (solve it once in the API gateway), and authorization (build a central identity service other services consume). Done right, SbD means developers can move fast without security being a final gate that blocks releases.
Default To Secure Settings
Secure choices should never be opt-in. Users should not have to actively make data private; private should be the starting state. On the Wix platform, for example, Collections (which act like a simplified database) are restricted to admin-only edits by default. Making content accessible to other user types is a deliberate change made via the Roles & Permissions feature.
Apply Least Privilege (PoLP)
Every permission granted is one that can be exploited. Users, employees, and services should all have the minimum access needed to do their job — nothing more. If you add a Blog Writer to your site, that person should not touch payment settings. When a breach or a CSRF exploit hits, least privilege keeps the worst of the damage contained.
In microservice architectures, start every new service with zero permissions. Developers can then request access through a self-service portal, or escalate to a data owner for particularly sensitive resources like databases containing PII.
Layer Your Defenses (DiD)
No single control is sufficient. Passwords leak, so add two-factor authentication (2FA). But even that isn't final — an XSS vulnerability can steal session cookies and bypass login entirely. Defense in depth looks at every layer of the stack as a potential attack point. Protect sessions with HTTP-only cookies, enforce timeouts, and bind sessions to devices. Do not assume an internal-only endpoint is safe: an SSRF attack can reach it. At Wix, this "breach mindset" means every developer checks permissions, input validation, and logic as if all upstream controls have already failed.
Reduce Attack Surface Area
The surest way to stop an attack is to not expose the system at all. Test and staging environments should never be publicly reachable; they are not production ready and make attractive targets. Inside production code, delete unused functions and endpoints rather than leaving dead code that could become an exploit path.
Fail Securely
Systems will fail — the only question is how. If a database goes down during a login attempt, your code should treat that as a halt: log the error, alert the right channel, and stop the execution flow. Do not drop a security check because of an unexpected exception. Whether it's a subtle issue like a DB returning a connection error or a misconfigured S3 bucket, the secure response is always to break the flow and return an error, not quietly continue with rights unverified.
Manage Third-Party Risk
Your attack surface includes the code you import. Malicious packages in the NPM registry have compromised countless sites, so it's essential to track what is actually in your dependencies. Keep a software bill of materials (SBOM) and review it regularly. Wix uses a Third-Party Risk Management Program (TPRM) that vets suppliers on an ongoing basis and runs regular security checks on their operations.
Keep Roles Separate (SoD)
An eCommerce site admin should never be able to place an order, nor should a customer have the power to promote themselves to admin. The point is that a single compromised account cannot take down everything.
Don't Rely on Obscurity
If things are hard-coded or hidden, hackers will find them eventually. Secrets in code get exposed. Randomly generated "secret" UUIDs in anonymous access links will end up in logs, cached in browsers, indexed by search engines, or stored in third-party analytics databases. Since you cannot guarantee a link stays hidden, assume it will be found. A short expiration time on such links means the window for discovery and abuse never overlaps — even if someone is examining traffic later, the UUID no longer works.
Keep Security Simple
Complexity is a security hazard. If a feature is hard to use, users will bypass it or use it incorrectly. Two-factor authentication is more secure than a password alone, but if it requires manual setup users only half-understand, adoption drops. Add functionality that feels simple but has unintended side effects, and the security posture degrades. Evaluate whether the value warrants the complexity, and keep whatever controls you have as streamlined as possible.
Check Your Work
Fixing a vulnerability is not the last step. Wix's Bug Bounty Program uncovers issues, but the fix involves more than a patch. Real understanding of the vulnerability is needed before rewriting code, and the person who found the bug often confirms the fix works. Follow that with regression testing to verify the issue wasn't reintroduced by a later rollback. Without that discipline, a closed bug can quietly reopen.
Security as a Company-Wide Mindset
Applying security by design across Wix wasn't limited to the security team. The principles were extended to every component of the system and embedded in the day-to-day work of developers, marketing, and sales alike. The goal was to make cybersecurity a shared priority rather than an afterthought handled by a dedicated group.
The reasoning is straightforward: as attack surfaces grow and hackers develop new methods to reach sensitive data, a reactive posture is no longer viable. Building with defense in mind from the outset gives an organization a structural advantage. A breach is not a question of if, but when, and systems designed with that assumption in mind are better positioned to absorb and contain an incident.
The approach applies whether you are building a platform from scratch or relying on a third-party, secure infrastructure. The same design principles can guide internal feature development and decisions about external dependencies.
Resources for Further Reading
For teams looking to formalize their security strategy, two resources are worth examining:
- The Open Web Application Security Project (OWASP) is a non-profit community focused on web security. It offers free open-source tools, training, and documentation to help teams improve software security practices.
- Wix's own trust center details the company's secure practices and can serve as a reference for implementing similar controls.
