Some startups see security as a nice-to-have that can be added months or years after launch. The smart ones realize that dependable security from the beginning means solid performance, satisfied customers, and no precious startup dollars wasted on fraud or incidents. F5 Labs decided to peek under the hood of one of these smart startups: Wanderlust Society. This Seattle-based company was created by a team of Amazon veterans looking to reduce the hassle while increasing the enjoyment of travel planning. Wanderlust Society created a web application that wrangles the long tail of personalized recommendations and the online community for travelers looking to take and share highly curated trips.

Goals

Before you begin building your architecture, it’s a good idea to have a well-defined idea of what you want. This goes beyond saying “we want to have the best web app ever!” It means clearly laying out the specific priorities. Wanderlust Society thought this through and set the following as the primary goals for their web application:

1. Mobile optimized
2. Secure
3. Fast
4. Highly available
5. Easily scalable

Risks

From these goals, risk assessments can be created. To build a security risk model, you use these goals to anticipate potential threats. Just like the importance of expressing well-defined goals, it’s insufficient to just say things like, “we want our site to be secure.” You need to create a risk model that is actionable so it can support designing defenses. Security can mean different things to different organizations, so risks needs to be detailed. The risk model will be used by developers and architects to make tradeoffs. An additional benefit from this risk analysis process is that it helps communicate security to the entire start-up team, both in terms of significance and the details of how specific threats can cause problems. Wanderlust Society did an excellent job of defining these:

1. Unauthenticated users should only be able to read or write data and APIs that are explicitly marked publicly available.
2. Authenticated users should only be able to see and change their own data.
3. Authenticated users should see shared data from other users.
4. Authenticated users should not be able to read or write non-user data such as system utilities and application support data.
5. Attackers should not be able to access the system by stealing an authenticated user’s credentials.
6. Attackers should not be able to steal authenticated users’ credentials in transit.
7. Attackers should not be able to steal/scrape Wanderlust Society data.
8. Attackers should not be able to intentionally crash, degrade, or modify site functionality.

This list is by no means carved in stone. It can and should be reviewed periodically and updated as conditions changed. It’s a good start, though. You may have noticed that “authenticated user” is called out but not defined. The details are the next step; what matters at this stage is spelling out what needs to be done, not how. Speaking of the next step…

Architect to Meet Goals and Address Risks

Once Wanderlust Society figured out goals and risks, they worked out architecture and security controls. They came up with the following:

Mobile Optimized

For a powerful mobile experience, the site needed to be super-fast to load (ties to Fast goal), so the core JavaScript is only 90 KB (compressed), and the dependency JavaScript is asynchronously loaded. Since it’s a single-page application, once the JavaScript loads, site navigation is incredibly fast (no waiting for multi-hundred milliseconds round trips to fetch more JavaScript, HTML, and CSS). This means that the site works great even on a slow 3G mobile connection. Goal one accomplished; now, on to the security goal.

Secure

Wanderlust Society built their application in the cloud and they also correctly realized that application security in the cloud is their responsibility. So, they had to build and configure the proper tools to lock things down to their specific risks.

First, the application was designed to respond only to HTTPS requests, so all communication is encrypted. Second, the application was partitioned with firewalls and rules locking down traffic in both directions (to reduce attack surface and exfiltration). Databases are in a restricted, non-public subnet and firewalled to a single port. This reduces the risk of attackers stealing data from users.

Access control is the way you ensure only authorized users can access or change data. The first part of access control is authentication. Passwords are a common way to authenticate users, but they are also fragile and a burden to manage properly. Wanderlust Society chose an alternate method and went with Federated Identity. This means their web application pulls from another trusted authentication repository such as a third-party website where a user is already registered. Wanderlust Society chose to federate from Facebook for two reasons. First, most people already have a Facebook account and this way users don’t have to create and manage another account. Second, Facebook’s infrastructure and platform have been out for years and are used by billions daily, so they’ve been proven reliable and secure.

The other half of access control is authorization: controlling which authenticated users can go where within an application. To securely track users, Wanderlust Society used a request/access token system for all service calls. When a user authenticates, he or she is granted a token tied to the originating client device. Because you never want to trust user input, the token is constantly verified at the server side. Another advantage is that tokens have a limited lifespan and are cleared on logout.

Since Wanderlust Society recognized that user input can never be trusted, they also built in server-side data validation checks¹ and parameterized SQL statements² to prevent injection attacks.

Wanderlust Society application services are based on the microservices architecture model³ where applications are small and generally focused around a small set of closely related tasks. This allows services to be independently deployable and expanded. Code is hosted in Docker containers within the EC2 instances, which is scalable to meet Wanderlust Society requirements.