Primer On Data Security: The Need-To-Know Guide For Product Managers
Have you heard about Code Spaces? It was a source code repository similar to Github.
Well, you've probably never heard of them because, despite being a promising product, they vanished almost instantly in June 2014 after a massive security breach. The breach resulted in them losing all their customer data, forcing them to cease operating.
After that incident, everybody in the digital world, including product managers, learned a lesson that should never be forgotten—PRODUCTS MUST BE SECURE.
In this guide, I will introduce you to the world of product security and help you keep security in mind when managing your products.
Why Product Managers Should Care About Data Security
In theory, product managers should just focus on retention, user interviews, and other non-technical stuff without worrying about security.
However, we live in a world of bad guys with malicious intentions who would be more than happy to steal your data (to sell it somewhere later on), encrypt it, demand ransom for it (a.k.a. ransomware), or simply do harm for the sake of doing harm.
So, apart from your activation and retention, you should also care about the immense business risk that lax security can pose to your product. A bad enough security breach will harm your reputation so much, that all of the years of hard work of your marketing, product development, and sales teams can vanish in a single day.
Moreover, you will end up facing legal action by your partners and customers whose data you failed to protect.
So, in my opinion, it is of utmost importance for product managers to be “security aware” when building and growing their products.
The 4 Most Common Security Gaps In Product Development
As a product manager, you don’t really need to have in-depth knowledge of the latest hacking methods and the ways to protect from them. This is something for your security and engineering teams to implement and handle.
However, you do need a basic technical understanding of how some of the most common security problems work and how hackers can exploit them. This will make your decision-making process more “security-aware.”
Let’s go over four such security gaps together and understand what they're about.
1. SQL Injection
Back when I was a youngster PM, I decided to learn a bit of coding and made a small (and horrible) PHP code that was serving as the backend of a contact form of a website. It would take in a message, store it in the database, and compose an email addressed to me with its contents.
When I showed this to a developer friend of mine, apart from barely holding his amusement (my code was just impossibly bad), he asked me if I had sanitized my inputs. As you guessed, I had no idea what he meant, and he explained to me that my databases were exposed to SQL injection without input sanitization.
SQL injection is the process of the hacker writing special SQL code instead of text in your inputs and ending up executing this code in your backend and getting unauthorized access to your product or stealing information from your databases.
Imagine that LinkedIn used this SQL query to check your password when logging in (disclaimer: they definitely do something smarter than the SQL here).
If, theoretically, the login page inputs were not sanitized, then you could type ' OR '1'='1 in the username and password fields and hit Sign In.
In this case, the backend would add your ' OR '1'='1 into the SQL query and would become something like this.
This query will return the value “true.” That means that you would be able to log into LinkedIn without having an actual username and password.
As I already mentioned, you can avoid this problem by sanitizing your inputs. Sanitization in this context means ensuring that whatever you type in the input fields is treated like ordinary text, even if you type code or SQL query.
With the sanitized inputs, LinkedIn will try searching for a user named ' OR '1'='1 in the database instead of executing the code. It will eventually fail to find it and give you an error saying there is no such person on LinkedIn.
Protecting yourself from SQL injections is one of the basic steps you can take to keep your customers’ data secure and avoid any harmful data leaks and unauthorized access.
2. Cross-Site Scripting (XSS)
XSS is another common way for hackers to manipulate your product and act maliciously on it. To imagine just how common XSS is, a Positive Technologies report estimates that around 90% of all web apps out there are vulnerable to this type of attack.
So what is it about? XSS looks a bit similar to SQL injection in terms of hackers manipulating your system to execute code that it was not supposed to. However, in this case, the malicious code executed is not in the backend/databases of your system, but in the frontend.
One of the funny and harmless examples of XSS is Twitter’s (yes, I still call it Twitter—try to fight me on it) self-retweeting heart emoji. It’s funny because nobody expected Twitter to screw up that massively, and it’s harmless because all it did was retweet itself.
This attack was just a simple tweet containing the following text.
As evident from the image, this is not simple text but a piece of code (Javascript with jQuery, to be precise) along with a heart emoji at the end.
Well, before Twitter fixed this security flaw, if you opened this tweet on your browser, the browser’s engine would recognize the content of it as valid code, hide it from the user, and run it. So, instead of the two lines of code, you would see just a tweet with a heart emoji.
When the code ran, it would navigate through the HTML of the page, automatically find the retweet button on your screen, and click on it.
It meant that anyone viewing this tweet automatically retweeted it - leading to a huge portion of Twitter users getting infected by it.
Now, imagine if it was not a self-replicating tweet but something more harmful, like a script that would scrape confidential information off your screen and send it to the hacker. Alternatively, a malicious code on your browser could take over your Internet banking web app and start transferring funds out of your account.
You get my point—XSS is still super dangerous despite being unable to access your servers and databases.
But how does it concern you as a product manager? Well, you might end up asking your engineers to give you cool features and integrations such as enabling your website to see the content of other tabs on the user's browser and doing something interesting with that info.
If you do and your team refuses to build such a feature, don’t get confused or sad because what you're asking for is essentially an XSS attack on other sites.
XSS is a fascinating area in cybersecurity, and there are lots of great books about it that I can recommend. My favorite is XSS Attacks by Seth Fogie.
3. Insecure APIs
Application Programming Interfaces (a.k.a. APIs) are the means of communication between your server and users’ browser or your application on their mobile device/desktop.
Whenever there is a need to obtain, store, or process data on your server, the browser/app (a.k.a. "clients") will send a request to the server with the necessary information. Then, the server will do the work and spit out the response.
For instance, when logging in, clients will send your username and password and ask the server to authenticate you. As soon as the server completes the request, it will send back a “success” message along with the page content the user should see when login is complete.
As APIs work with user data, they are also prone to security vulnerabilities that can lead to malicious manipulation of data (e.g. asking the server to perform a money transfer in the user’s name) or data breach (e.g. asking the server to reveal the medical records of the user).
The most common types of API vulnerabilities are:
No authentication: In this case, the API does not require the client to prove identity before it provides confidential information. To get a sense of how this works, imagine someone went to the bank and asked to withdraw money from Mark Zuckerberk’s account, and the cashier just replied, "Sure, how much?"
No rate limiting: Here, APIs will not stop processing requests, even if there are just too many of them—like, way more than there were supposed to be—leading to your server overloading and going down. This type of excessive torrent of requests happens when someone tries to do a DDoS attack on your servers.
Excessive data exposure: This is when your API responses contain information you don't really want people to access. For instance, when sending money to someone via internet banking, let's say the API notification that the transaction was a success also contains the account balance of the recipient, which is something you are definitely not supposed to see.
The solutions to these three vulnerabilities are kind of obvious. Ask for authentication when serving sensitive data, add rate limiting, and make sure that you are not serving data that is not supposed to be there.
If you want to explore API security a bit further, you can check out Neil Madden’s book on it.
4. Lack of Encryption
My head of security loves to constantly repeat that a well-executed cybersecurity strategy on a product looks like an onion—it consists of multiple layers of security over different parts of the product.
Whatever we have discussed so far was security risks at the surface layer, when the user cannot access your servers or databases and tries to attack “from the surface.”
However, if a hacker somehow ends up getting full access to your servers (penetrates the first layer), you should still have measures in place to protect your databases from their unauthorized access—keeping your inner layers secure, too.
One of the best ways to protect your data, in this case, is encrypting it. It means that even if someone accesses your databases and downloads that data, it will be a bunch of gibberish for them as it is encrypted.
Only the company or the user—the two parties who have the encryption key—would be able to decrypt that gibberish into useful information. Unfortunately, however, forgetting to encrypt the data on servers is super common and has led to numerous massive data leaks.
I have personally seen too many websites and products that have rolled the dice by storing the passwords of their users in plain text—something that is considered a deadly sin in software. The best practice for this case is to run the password through a hashing algorithm, get an encrypted version of it (called a hash), and store that instead.
The beauty of this is that both the user and the company have the key to return the hash into its plain text form and use that password for authentication. But, if a hacker accesses the DB and downloads the hash, turning it back to the original password would take them millions of years of calculations without the key. (I’m not kidding, that’s the real number!)
Encryption is another fascinating area in cybersecurity I recommend that you check out. In particular, you can start by learning how Public Key Cryptography works, as it is what the entire internet is running on now.
Integrating Application Security Into The Product And Software Development Lifecycle
With all of these vulnerabilities and best practices in mind, let’s focus on an obvious question that you might have—how do I keep my products secure as a PM?
I thought you'd never ask! Here are two important security best practices that can help you with that:
Secure Products by Design
This is a development process approach that says you should keep security requirements in mind from the very moment you start building your products so that security measures are natively integrated into your code and architecture instead of being added later in the SDLC.
The latter is usually much more expensive and does not have the same level of protection as “natively” secure software.
So, as a product manager, it is your responsibility to ask your development team to follow this approach and refrain from deprioritizing items that help build security into the product.
Regular Security Audits
The majority of products that I have managed would get regular security testing (usually once every six months to a year). We tested the entire security posture, and it included:
- Penetration testing
- Threat modeling
- Security controls review
- Security strategy and security features review
- Supply chain and automation workflows review
- Code analysis (including open source code we used and the code obtained from 3rd party partnerships)
- Security roadmap and metrics creation
- Risk assessment
- ...and more!
This is important because your product is constantly evolving, and you might accidentally break your software security while adding something new. Regular audits will quickly identify these problems and let you fix and validate them—before a bad actor finds them first.
As a product manager, your job is to allocate time and prioritize these audits and the code cleanups that follow.
Trust Your Security Folks
Whatever feature you plan to build and whatever action plan you have to crush your growth targets, always make sure you have run your ideas by your security team.
And listen—it might seem to you that the security folks want you to “oversecure” your product. However, most of the time, if they don’t like your idea, you should consider making changes to it. It's just not worth the risk otherwise.
And on the topic of considering things, also consider subscribing to our newsletter to get lots of product management guides and articles straight into your inbox!