Building Secure By Default Mobile Apps According to Facebook

With thousands of Facebook developers pushing code at an average rate of three to four times a day, writing code that is “secure by default” is critical to avoid introducing security vulnerabilities. Although secure by default code is not a new idea, it’s something many developers and companies still struggle to implement. At Facebook, we supplement traditional security reviews with tooling and best practices designed specifically for developers, which makes their jobs easier while delivering security benefits.

Even with all the sophisticated systems and tools we have at Facebook, we still expect our developers to practice fundamental secure development. Below are a few things every developer should be doing to protect their code from some of the most common security vulnerabilities, ranging from strategic fundamentals to specific coding techniques. Following these best practices can be even more important if you’re an independent developer or work for a small team without dedicated security support.  

1. Know your threat model. Think about who might want to access your production systems and data, and focus on ways to mitigate these predicted threats. You can’t guess every way an adversary will attack your system, but thinking about the ways that your code may be used and abused is a great way to start hardening it.

The Open Web Application Security Project (OWASP) offers an excellent write-up of a traditional threat modeling process, decomposed into 3 high level steps:

  • Decompose the application to understand how it is used and how it interacts with external entities.
  • Determine and rank threats from the attack and defense perspective. You can classify the security risk for each threat using a value-based risk assessment model such as DREAD (Damage Potential, Reproducibility, Exploitability, Affected Users, and Discoverability) or general risk factors such as likelihood and impact.
  • Determine countermeasures and mitigation to protect against threats. Using the risk ranking you assigned, sort threats from the highest to the lowest risk, and prioritize your mitigation efforts.

2. Use updated libraries. Libraries are usually the largest attack surface for your app, and the risks increase exponentially as you add more code. Whether you’re using open source, proprietary code, or a combination of both, make sure you’re only using the latest version with all available changes and improvements.

If you want to use open source libraries, here are a few that Facebook manages:

  • React - a declarative, efficient, and flexible JavaScript library for building user interfaces.
  • Pop - an extensible iOS and OS X animation library, useful for physics-based interactions.
  • Rebound - a Java library that models spring dynamics and adds real world physics to your app.

3. Be careful when using high-level language features (like ’exec’ in PHP). Misuse of these features can cause shell injections and enable an attacker to compromise your system.  Failure to properly sanitize user input is one of the leading causes of Web vulnerabilities on the internet. To protect against these vulnerabilities:

  • Avoid using input directly from users as much as possible - always sanitize it first.
  • Don’t use primitive string operations to produce structured output, whether it’s a shell command, database query, some HTML, or JavaScript. Instead, choose a framework that enables you to express the higher-level thing you’re trying to build.

At Facebook, we built and open sourced XHP, a PHP extension which augments the syntax of the language to both make your front-end code easier to understand and help you avoid cross site scripting attacks. For React.js and React Native, we developed JSX, an inline XML syntax for JavaScript code.

4. Guard against SQL injection. SQL injection is not just one of the most commonly exploited Web vulnerabilities - it can also destroy your database.

You can help protect your code from SQL injection with the following methods:

  • Adopt an input validation technique to authenticate user input against a set of defined rules for length, type, and syntax, in addition to validating against business rules.
  • Individuals with permission to access the database should also have the fewest privileges. Do not use system administrator accounts like “sa” for Web applications. Access to a database should be limited to a specific application and should not allow access to other applications.
  • Use strongly typed parameterized query APIs with placeholder substitution markers, even when calling stored procedures.
  • Be careful when using stored procedures as they can be injectable through the use of exec() or concatenating arguments within the stored procedure.

5. Understand exposed APIs. Exposed APIs can allow unauthorized access to your code, including remote access to manipulate an object.

Here are some ways to protect your APIs from exposure and manipulation:

  • Remove old deprecated function calls from your APIs.
  • Don’t embed API keys, passwords, etc., directly into code - always keep these separate. Store this information in a separate configuration file. If a configuration file is part of a project in an IDE, remove sensitive data before distributing or sharing.
  • Store sensitive data in a secure system with strong encryption. The system should also utilize immutable audit logging (IAL).

If your app integrates with Facebook, we also provide an App Security Checkup tool, which helps detect potential security vulnerabilities in your apps and helps you address them.  If your app integrates with APIs from other providers, be sure to take advantage of any security tools, notifications, and other security-related initiatives they may offer to help developers secure their apps.

Are there other best practices that you’ve found particularly helpful? Please let us know in the comments below.

This article was co-authored by Facebook Production Engineer Melita Mihaljevic

Be sure to read the next Security article: Daily API RoundUp: CrowdStrike, Brafton, mNectar


Comments (0)