How Attackers Think: Understanding Your Attack Surface Before They Do

Most breaches don't start with a sophisticated attack. Instead, they start with a door someone forgot to close and an attacker who noticed it first.

As Dashlane’s CTO, I’ll be exploring this topic below in the first post of a new blog series in which I share the security principles and architectural decisions behind how we build Dashlane, as well as what any organization can take from them.

I was inspired by Neo Kim and Saed Farah's excellent 21 Cybersecurity Terms Every Software Engineer Must Know. It reminded me that the fundamentals are worth being repeated clearly and often.

Given that we recently revamped our own public Security Principles & Architecture documentation, now is the perfect time to bring some key security concepts to life.

In early 2025, a threat actor breached Oracle's cloud identity infrastructure not through a cutting-edge exploit, but by walking through a door Oracle had forgotten it left open. The entry point was a legacy server, part of Oracle's older Gen 1 infrastructure, running software that hadn’t been patched since 2014. The server was still internet-facing and holding live identity and authentication data for over 140,000 enterprise tenants.

Around the same time, attackers ran a large-scale payment card skimming operation against dozens of online retailers by abusing a deprecated Stripe API endpoint. That endpoint had been retired from Stripe's active product but never fully decommissioned. It was still connected to backend payment validation systems, and it lacked the security controls built into Stripe's more modern APIs.

Two different companies, and two different attack methods, yet one common root cause: Part of their attack surface was invisible to them, but not to the people actively looking for ways in.

Most breaches start with such neglect, rather than a technical feat.

Your attack surface is every point where an attacker can interact with your system. Most engineers instinctively think about login pages and public APIs.

The reality is much broader. It can include your:

This means every feature your team shipped, every dependency you pulled in, and every account that was never deprovisioned when someone left.

Think of your organization as a building. You secure and lock the front door. You probably know where the fire exits are. But do you know about the service entrance at the back that an old contractor used? The ventilation shaft that connects two wings? The server room that still has a default password from 2019?

The attack surface is the full blueprint of that building, including the parts your team no longer actively thinks about. And it grows every time you ship a feature, add an integration, or onboard a new vendor. It’s never static.

Knowing your attack surface is the first step. Threat modeling is what you do with that knowledge.

A threat model is a structured exercise built around one central question: "If someone wanted to break this system, how would they do it?"

You start by identifying what needs protection, such as user data, credentials, financial records, and internal communications. Then, you examine every entry point and ask how each one can be abused.

What makes threat modeling valuable is both the mental exercise and the consequences. When your engineers run through these questions against a new feature before it ships, they start thinking like attackers, not just builders. That changes the code they write, the defaults they choose, and the questions they ask in design reviews.

At Dashlane, threat modeling is strongly embedded in our software lifecycle. Our engineers try to anticipate how attackers could exploit new features when they design the architecture and the technical details. As an example, you can see how this was done recently for our link sharing feature.

Our entire architecture is built on what we call assumed breach. Our threat model assumes that motivated, well-resourced attackers will target our users, infrastructure, and supply chain. Thus, we design for the scenario where any of those layers could fail or already be compromised.

We know 100% security is not achievable, but we architect the system so that a breach of one layer doesn’t cascade into a full compromise. We aim to minimize the blast radius of an incident.

Concretely, we model against five primary threat classes:

If you compare architectural approaches, in a minimal architecture, all user data is encrypted with a single central key. If you steal that key, the user's data is accessible at once. Many common cloud architectures improve on this by deriving keys per user, but they couple encryption and authentication in a way that creates its own vulnerabilities at the server layer.

Dashlane's zero-knowledge architecture separates these concerns entirely: Vault encryption happens locally on the device, with a key derived from the user's master password, while server authentication operates through a separate, per-device key. The result is that even a full infrastructure compromise would limit the ability for an attacker to access user data.

This is what Secure by Design means in practice: Security embedded into architectural decisions from day one, not added as a layer afterward. We reinforce that commitment operationally with formal threat modeling in our development lifecycle, annual independent penetration testing, and a bug bounty program on HackerOne that invites researchers to continuously stress-test our assumptions.

A few ideas to consider when thinking about attack surface and threat modeling:

Most organizations I speak with have done some version of this work. They have a list of systems, a rough sense of their exposure, and good intentions around threat modeling. What they often lack is the discipline to treat it as a continuous practice rather than a one-time exercise. That gap is exactly what attackers count on.

In the next post, we’ll look at why identity and credentials are now the primary target and how to think about protecting them systematically.