Your users want to easily share digital items like referrals, coupons, ecards, invitations and hyperlinks with their contacts, or quickly see a list of people they know already using your service, and letting them view their address books on your website is clearly the best user experience to accomplish that. Handling sensitive address book data safely and respectfully is not easy.
This article describes everything CloudSponge does and all the tools we use to keep our customers’ sensitive data safe so that you have the answers you need to confidently choose our service rather that building Contacts API integrations with Google, Yahoo, Microsoft, AOL, iCloud and dozens more yourself.
Since 2010, we’ve processed tens of millions of address books and trillions* of email addresses. In fact, at the time that we’re writing this article, more than 2 trillion email addresses have passed through our servers in the last 12 months. We know a thing or two about handling these sensitive payloads.
There are many risks involved in handling address book data. Any vulnerability in your system creates a way for hackers to steal the data and capitalize on lucrative black market opportunities.
It’s also crucial to consider privacy. Data security is not just an ethical obligation, it’s a complicated and expanding legal one as well. The EU General Data Protection Regulation (GDPR) is the most well-known, but your business may also need to be compliant with CCPA, PIPEDA, and others. These regulations are more than a string of acronyms, they’re a legal commitment to the privacy of your users and their personal data.
To tackle the threat of hackers while complying with privacy regulations, you need to consider how to design your system for security—everything from architecture and data flow design, to your software development practices and hosting decisions. After your system is up and running, proper monitoring and incident response protocols are critical. This is a dynamic and ongoing responsibility which requires robust and adaptable security practices and processes to ensure the continued security of your system and privacy of your customers’ data.
CloudSponge is used by Airbnb, Lyft, InVision, GoFundMe, SurveyMonkey, Yelp, Nextdoor, and many other companies that prioritize privacy and security as a part of their core values. They trust us to keep their users’ contact data safe whether they’re using the Contact Picker or the Contacts API. Now we’ll explore how we keep their data safe.
Design for Security
Handling sensitive address book payloads from your users means that security needs to be a core value that informs all of your engineering organization’s decisions and processes. To do it right, you need to design for security right from the start.
Considering the security and privacy of customer data provides the foundation for our architecture design, key components of our software development processes, and the core of our hosting decisions.
Software architecture
Our systems are designed for data privacy and security first, so the contacts that we transmit from your users to your service never get saved to disk. Our architects design it this way to ensure the security of the data containers without compromising the privacy of the contents.
Here’s how we do it.
The Contacts API holds data in memory using Redis. Data gets held in memory for a few minutes, long enough for customers to retrieve contacts using the API, and then it gets deleted. To help keep your data private and secure, we don’t back up any of the data in Redis to disk. It’s intentionally ephemeral.
Our architecture normalizes contacts data while it passes through Redis. By normalizing while streaming the data, no database or long-term storage is needed, keeping contacts data private and secure.
Due to the absence of an OAuth authentication layer some address book providers (looking at you, iCloud) can only be accessed with a username and password. Just like address book data, this is sensitive information, so we don’t persist that data on disk either. The username and password provided by the user get stored in local memory while the Contacts API retrieves contacts from the address book source. After the contacts are retrieved, local memory is obliterated with a garbage collection process.
While architecture design is vital to privacy and security, software design matters just as much.
Back-end service design
Building software that puts security first might seem easy at first. Best practices for secure software design are well-documented, so all you have to do is follow those practices and you’ll be producing secure software, right?
Wrong.
We’ve been there. We know that for every change we want to make, every new feature and line of code, we have to consider the effect on our security posture. Coming up with the design is the first step—adhering to it and improving on that design over time is where the real hard work comes in.
At CloudSponge we value innovation. We want to take advantage of new technology, but we know that security is important. We carefully assess third-party technology, reviewing it for known vulnerabilities before implementation, and we add new features that incorporate secure designs.
We write secure software that works exactly how you need it to. The design of the Contact Picker software and the Contacts API puts privacy and security first. For example, when CloudSponge retrieves the contacts of your customers, any API calls send personal data in the body of the request, rather than sending it via sniffable query strings. We also make sure to set the HTTP headers on the API such that contact data isn’t cached by the browser or other intermediaries on the internet. These API considerations are just a couple small examples of how we ensure the privacy of your data.
It’s easier to keep data private if we don’t store it at all, so we filter out sensitive data before it is logged. Instead, we only store a unique identifier and metadata about how many contacts were retrieved from an address book, the minimum amount of data necessary for us to monitor the status, and use of CloudSponge services.
Front-end privacy considerations
Privacy and security consciousness is not just a back-end consideration – the user experience and interface are just as important. We make sure to provide our customers and their users with granular privacy settings. The Contact Picker includes data retention options to help users keep their data secure and private, with smart defaults to balance privacy with convenience. The contact picker runs in the user’s browser, keeping all the data on the client-side, and provides three levels of data retention options:
- The most private option doesn’t store the data anywhere, except in the contact picker while it is running. If the contact picker closes, all traces of the contacts are deleted.
- The middle option is the default, which stores the data in the browser memory while the browser window is open. When the user refreshes the page or navigates away from it, the data is deleted.
- The third option allows customers to enable the user’s browser to persist the address book data in local storage, and for how long. The Contact Picker can be configured to allow address books to be cached for a specific period of time, but the data can never be cached indefinitely.
It’s important for everyone using the service to be in control of their data. Address book data is valuable and personal, and we respect the user’s right to keep it private.
Software development
Developing software well takes time and effort. Some development best practices can focus on seemingly trivial details like the eternal “tabs vs spaces” debate, but the best ones also focus on security.
Improperly-written code can lead to buffer overflow vulnerabilities and memory leaks, letting attackers access sensitive data that never should have been available. If you don’t consider potential misuse of input fields or dialog boxes, you’ll be vulnerable to SQL injection, with aspiring spammers writing code to trick your website or application into leaking the contents of your database. Cross-site scripting (XSS) vulnerabilities can turn your website into a distribution point for malware or more sophisticated attacks, because you forgot to escape or encode some data in your code.
Whenever you’re building something, you want to make sure it’s built right. It’s one thing to design something securely, it’s another to make sure it’s actually built that way. That’s where secure development practices come in.
We design our services to be secure and private, so we also make sure to follow secure development practices. Each pull request is reviewed before being committed, and the code reviewers include the security issues in the Open Web Application Security Project (OWASP) top ten list in their reviews.
In addition to manual reviews, we also use automated tools to check for security vulnerabilities such as XSS and DOM attacks. Every time new code changes are committed to the code repository, the ruby gem brakeman runs, checking for security vulnerabilities by performing a static analysis of the code. Any issues found by brakeman cause the build to fail, preventing the code from being deployed to production and requiring the developer to fix the issue right away.
To review the code used by third-party libraries that CloudSponge uses, we use the bundler-audit gem and the npm audit command. Bundler-audit checks for security vulnerabilities in Ruby gems bundled by our code. Just like brakeman, this tool also runs every time code is committed to the repository and if it finds something, the build fails and the developer must address the issues. We run the npm audit command to check for security vulnerabilities in our JavaScript dependencies.
Secure hosting
It can seem like a good idea to host everything you do on servers that you own and manage. But when you control all of your servers and hosting you’re solely responsible for maintaining the servers. You therefore have to be prepared for any zero-day vulnerability that could mean emergency patching, or an immediate response to a distributed denial of service (DDoS) attack that hits your infrastructure. A misconfigured server could become host to a botnet, or expose sensitive data to the public internet.
We host and run our software on AWS because it’s a vendor with strong security practices while balancing our need for a reliable and available service. We configure AWS using best practices, setting up a web application firewall and using load-balancers to manage traffic and protect our servers from the public internet.
Security monitoring and response
Monitoring and responding to security incidents is a must for any modern business. All it takes is one devastating hack to ruin customer trust and the reputation of a company. With that threat looming, it can be intimidating to set up the security practices necessary to prevent, monitor, and respond to security incidents efficiently and effectively.
We know that it’s difficult to balance investments in security practices with innovating and improving on features and functionality. We also know that our products and services would be worthless if they threatened the privacy of our users due to lax security practices. We’ve invested our time and resources into security monitoring and incident response, as well as proactive security measures like vulnerability scanning.
At CloudSponge, we closely monitor our network and services for potential security incidents and vulnerabilities. Using Wazuh, we get alerts on file changes, hacking attempts, and various 500-level server errors that could indicate nefarious behavior. Every alert is investigated within 24 hours, if not immediately.
We also monitor third-party dependencies in our code using Github’s vulnerability monitoring service. This service is always monitoring the code and helps us discover known vulnerabilities that affect the Ruby and JavaScript code and libraries used in CloudSponge. These vulnerability alerts are valuable to help us investigate and determine the best course of action.
Vulnerability scanning is a vital portion of our web application security practices at CloudSponge. Detectify is run on a weekly basis, generating alerts with whatever is found. Those alerts are treated as security incidents, investigated within 24 hours and mitigated as needed.
In addition to Detectify, we use the OpenVAS vulnerability scanner to do a scan every month. OpenVAS helps us mimic a worst-case scenario—a hacker gaining access to our services with all network ports open—and remove or mitigate any risks revealed by the scan results.
For anything we can’t find ourselves, we provide a bug bounty to enterprising developers and white hat hackers that find vulnerabilities in our code.
Beyond web application vulnerabilities, we make sure our infrastructure is protected from other security risks by following patching best practices for our servers. Using the details in CVE vulnerability disclosures by US-CERT alerts, we assess the risk of newly-announced vulnerabilities on our infrastructure. High-risk threats, such as those with remote code execution possibilities and available proof of concepts, are mitigated by testing and patching our servers within 24 hours. Lower-risk threats are covered by our regular monthly patch process for our infrastructure.
Security processes
Setting up processes can help your business work more efficiently. Some processes can help make your business more secure, too. Restricting access to servers with sensitive data, requiring approvals for network access, and mindful provisioning processes can help reduce your attack surface.
Lax security processes can let hackers run rife through your critical servers. With access to just one account on your network, they can traverse your infrastructure and escalate privileges until they have root on your most critical services, able to do whatever they wish to your business.
Here at CloudSponge, we have processes in place to assure operational security in everything we do, in addition to our diligent security practices. We practice the principle of least privilege, granting access to vital servers and services on a need-only basis, reviewing access with job changes. We frequently rotate keys and secrets used to access critical servers. We even have detailed policy and procedure documentation, ensuring that our services are secure and compliant with industry regulations such as PCI.
Protect your users’ contact data with CloudSponge
For over 10 years we’ve followed best-in-class security processes and practices to stay compliant and secure. Everything from our hosting decisions, software and architecture design, and our development practices are influenced by security and privacy decisions. We face the legal, compliance, reputation, and security risks involved in handling contacts data for thousands of customers.
Most companies are up and running with our Contact Picker or Contacts API within a couple hours, which gives them stable, secure, maintenance-free integrations with dozens of address book providers around the world. We have weekly onboarding webinars, a Slack channel, and amazing email support to make sure you get exactly what you need from our products as quickly as possible.
Ready to do this? Start with a 14-day trial now (cancel anytime).
* Astute readers will notice that this number is much larger than the number of global email users (currently estimated at about 3.9B by Radicati). We have estimated this number based on assuming that every contact record that passes through our system contains exactly one email address. Furthermore this figure is inflated because we may be counting each address book multiple times. So while the actual number of unique emails that pass through our system is much lower, we’re unable to say exactly how much since we delete all the private information and have no way to de-duplicate the contacts.
