Secrets in Source Code - How Your JS Code is Exposing Your Credentials

Rate this content

Secrets like API keys are constantly leaking through source code. The 2021 State of Secret Sprawl report found over 6 million secrets in public git repos. This presentation reviews the new, unreleased, 2022 State of Secrets Sprawl report focusing on how JavaScript source code specifically leak secrets.

11 min
06 Jun, 2023

AI Generated Video Summary

This lightning presentation discusses the issue of secrets leaking in code and how it can expose digital authentication credentials. GitGuardian scanned over 10 million secrets in public repositories on GitHub, with Python being the top language for leaked secrets. The exposure of secrets can occur in both public and private repositories, and it is important to avoid hardcoding secrets and store keys securely. Best practices for handling keys and secrets include using a centralized place for storing keys, using tools like .env for loading secrets, and implementing vaults and secrets managers.

1. Introduction to Secrets in Code

Short description:

In this lightning presentation, I'm gonna talk about secrets inside code and how your applications or you react applications may be leaking your secrets. Secrets are digital authentication credentials that grant access into services and allow for data ingestion and writing. Our applications are a collection of different services, like Okta for authentication, Stripe for credit card processing, and MongoDB for managing databases. GitHub is a platform where we scan code and find a huge amount of data, including secrets, with over a billion commits made to public repositories.

Hey, everyone. My name is Mackenzie. I'm a developer and security advocate at GitGuardian. And in this lightning presentation, I'm gonna talk about secrets inside code and how your applications or you react applications may be leaking your secrets.

So good place to start is really what are secrets. When I'm talking about secrets, I'm referring to digital authentication credentials. These are typically things like your API keys, your credential peers, like your database credentials, security certificates, anything that grants access into services, or allows you to ingest data or write data. Really, these are the crown jewels of any organization because an attacker is going to go after these immediately when they make access into anything, allows them to persist their access or move laterally into different systems, elevate their privileges, and they can do all of that while remaining undetected because they're properly authenticated into services.

So to understand how we use secrets, let's take a step back and look at how we build application. No longer are we building monoliths. Our applications are more or less a collection of different services. So for example, we may use Okta to authenticate users into our systems. Maybe we're using Stripe to process credit cards. MongoDB is a managed database. So very quickly, our applications can become a collection of all these different systems.

One of the things we do at GitGuardian is we scan code around the place to try and identify where these secrets are. And we release it in a report each year called a State of Secrets For All. One of the places that we scan is You're probably familiar with it. Lots of developers are. In fact, at 2022, 94 million developers were using GitHub according to GitHub themselves. And we've crossed the 100 million developer mark by now. And last year, just last year, over a billion commits were made to public code repositories. Just public code repositories. So that's a huge amount of data. 84 million new repositories were made. Again, just public. So this is a literal firehose of information. You can find anything and everything in GitHub in public repositories, including secrets. So there's 1 billion commits.

2. Secrets Detected in Public Repositories

Short description:

GitGuardian scanned over 10 million secrets in public repositories on GitHub, including valid cloud provider keys, messaging systems, database keys, and keys to version control platforms. Python was the top language for leaked secrets, followed by JavaScript. Hard-coding credentials in main files like app.js and index.js is a common but insecure practice. Configuration files for specific services, like Docosaurus, can also expose keys. Hackers do monitor GitHub for these credentials.

GitGuardian actually scanned every single one of them last year. We scan them for secrets. In fact, nearly 400 different types of secrets we were looking for. And what did we find? We found over 10 million secrets that were detected in public repositories in GitHub. 10 million. This is a big increase from previous years. The first year we released this report was in 2020 when we found 3 million, and you can see the progression to 10 million now.

Partly this is explained by more developers on GitHub, but it's also explained because we're actually using more and more secrets every year. Now we have different things like Infrastructure as Code, which is the fastest growing segment on GitHub. We're now programmatically managing our infrastructure, so we need to use secrets to do that. So more secrets, more leaked secrets on GitHub. There's a whole bunch of lots of information that we can find on GitHub. We look for specific secrets and we validate them when we find them. Some of the more interesting things that we found are, for example, that 20% of the secrets that we found were for cloud providers, things like Google Card Services or AWS. And again, these are valid credentials. So this is 2 million valid cloud provider keys that we found in public places in GitHub. We even found lots of different things like messaging systems, database keys, and even keys to your version control platform. So this is access to your private repositories that you put in a public repository.

So a lot of the extensions that we found here, Python was the number one language that leaked secrets, but JavaScript is really the second language when we exclude JSON and ENV files, which are really language agnostic files. But we're just looking here on this slide at JavaScript file extensions. Now, it may not be a surprise that app.js or index.js are really the number one applications. And this is really a main file where the developer has hard-coded their credentials into their source code. Now, this is a very bad practice, but it doesn't come as an overall surprise. But we can find some interesting things as we look through this data. For example, we have configuration files for specific services. So Docosaurus is kind of like an out-of-the-box framework to build websites on. And it comes with a configuration file. You can just simply replace the example text and put your own keys in here, and commit this to GitHub. And now you've just exposed your keys. So is this really a security risk? Do hackers actually monitor GitHub for these credentials? The answer is yes.

3. Exposure of Secrets in Repositories

Short description:

Secrets can be leaked from both public and private repositories. The Lapsus Group has publicly released the source code of major companies, showing that private code is not safe. Source code is spread across various platforms, including developers' machines, backups, wikis, messaging systems, and Git repositories. Even if you don't have open source repositories, secrets should never be in your code. To prevent exposure, avoid hardcoding secrets and store keys on the backend instead of handling them directly on the front end.

Very frequently. One example that we had last year was with Toyota, where a contractor working for Toyota accidentally leaked public keys, accidentally made a private repository public, which leaked keys to a database that Toyota's mobile application was using, a mobile application called T-Connect. So these are keys that gave access to all the user's information that were using T-Connect that were sitting out there in a public repository. So this is just one example, but there's many, many, many more examples of where real keys belonging to organizations having real consequences have been leaked out in public places.

But it's not just public repositories that you need to worry about. It's your private repositories, too. Source code that is private is always accidentally finding its way out into public places, or as I call it, involuntarily open sourced. The Lapsus Group, for example, last year publicly released the source code of NVIDIA, Samsung, Microsoft and many, many more. You may ask, how did they gain access to private source code? Well, there's lots of different ways. Source code is a very leaky asset, which means it's sprawled everywhere. It's on your developers' machines, it's backed up, it's in wikis, it's shared over messaging systems, and of course, it's in your Git repositories. Also, a lot of people have access to your Git repositories. And I know for a fact that Lapsus was simply paying employees to grant them access to public private source code. So it's not that difficult for a threat actor that's motivated to access your private source code. So if you're thinking you're safe because you don't have open source repositories, you're not. Secrets definitely should not be in your code regardless of where they are.

So why do secrets get exposed? There's lots of different ways. Maybe you're committing things and you're testing out keys so you've hardcoded them in there, not realizing that those keys are going to be in your history forever. Even if you do something on a development branch, you hardcode credentials, you quickly remove them later because you're just testing it, those credentials are still going to be in your Git history and they're going to be there forever. They can be printed out in auto-generated files like debug logs. You can include sensitive files in your Git repositories like .env files or .pem files. They should never be in your repository so make sure you use a .gitignore file and you can also accidentally push code to the wrong place. So how do you prevent them from doing this? Well, you should never hard code secrets, never directly type in the secret into your application. That's rule number one, doesn't matter if it's private, public or what kind of branch you're working on or for how long it's there. It will be there forever in Git. We also can use tools to prevent them from being leaked. So we can use tools to enable us to do this. So we want to store keys on the backend. If you're building a React app and you're making it look pretty, we want to make sure that you're accessing your credentials through the backend and it's passing you the data that you need and you're not dealing with it directly. And there's not many scenarios where you actually need to handle those keys on the front end.

4. Best Practices for Handling Keys and Secrets

Short description:

Store keys in a centralized place like a .env file. Use tools like .env for JavaScript to load secrets into environment variables. Use vaults and secrets managers, rotate keys regularly, and restrict access. Sign sensitive keys with a hash of the application. QR codes on the screen provide more information on secrets management.

If you are handling keys, make sure you store them in a centralized place. For instance, a .env file. Just make sure that this .env file is added into your .gitignore file so it's never included in your Git repository. You can use great tools like .env for JavaScript, which will load your secrets and local memory from your .env file into environment variables, meaning that your application won't accidentally them and they won't need to be in your Git repositories.

If you want to go a step further, we should definitely be using vaults and secrets managers. We need to rotate our keys regularly so that even if a key does get leaked, you're on a rotation schedule so it won't be valid for long, and we need to restrict the access of the key. We should restrict it down to just the services that we expect, so if a threat actor gets it, they can't do anything with the key.

For sensitive stuff, we should be signing those keys with a hash of the application that's using it so that we're absolutely certain that everything that's being used is for legitimate purposes only. So thank you very much. There's a couple of QR codes on the screen. One will take you to the state of secrets we'll report for 2023, and the other will look at a secrets management maturity model of how you can correctly handle your secrets in various different ways. Thanks for listening.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
JSNation 2023JSNation 2023
30 min
The State of Passwordless Auth on the Web
Can we get rid of passwords yet? They make for a poor user experience and users are notoriously bad with them. The advent of WebAuthn has brought a passwordless world closer, but where do we really stand?
In this talk we'll explore the current user experience of WebAuthn and the requirements a user has to fulfill for them to authenticate without a password. We'll also explore the fallbacks and safeguards we can use to make the password experience better and more secure. By the end of the session you'll have a vision for how authentication could look in the future and a blueprint for how to build the best auth experience today.
React Advanced Conference 2021React Advanced Conference 2021
22 min
Let Me Show You How React Applications Get Hacked in the Real-World
Modern frontend frameworks like React are well thought-of in their application security design and that’s great. However, there is still plenty of room for developers to make mistakes and use insecure APIs, vulnerable components, or generally do the wrong thing that turns user input into a Cross-site Scripting vulnerability (XSS). Let me show you how React applications get hacked in the real-world.
JSNation 2023JSNation 2023
22 min
5 Ways You Could Have Hacked Node.js
All languages are or were vulnerable to some kind of threat. I’m part of the Node.js Security team and during the year 2022, we've performed many Security Releases and some of them were really hard to think about.
Did you know you can make money by finding critical vulnerabilities in Node.js? In this talk, I’ll show you 5 ways you can have hacked Node.js and how the Node.js team deals with vulnerabilities.
JSNation Live 2021JSNation Live 2021
9 min
Securing Node.js APIs with Decentralised Identity Tokens
Authentication and Authorization are serious problems. We often dedicate a lot of time to craft powerful APIs but overlook proper security measures. Let's solve it with Magic using a key-based identity solution built on top of DID standard, where users’ identities are self-sovereign leveraging blockchain public-private key pairs. In this talk, we’ll look at proper ways to secure our Node.js APIs with Decentralised Identity Tokens. We’ll go from learning what Decentralised Identity standards are, how the users’ identities are self-sovereign leveraging blockchain public-private key pairs, why they’re the future of API security, and to put theory into practice we will build a real-world implementation using Node.js where I’ll show common best practices.

Workshops on related topic

React Summit 2023React Summit 2023
56 min
0 to Auth in an hour with ReactJS
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool. There are multiple alternatives that are much better than passwords to identify and authenticate your users - including SSO, SAML, OAuth, Magic Links, One-Time Passwords, and Authenticator Apps.
While addressing security aspects and avoiding common pitfalls, we will enhance a full-stack JS application (Node.js backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session securely for subsequent client requests, validating / refreshing sessions- Basic Authorization - extracting and validating claims from the session token JWT and handling authorization in backend flows
At the end of the workshop, we will also touch other approaches of authentication implementation with Descope - using frontend or backend SDKs.
JSNation 2022JSNation 2022
99 min
Finding, Hacking and fixing your NodeJS Vulnerabilities with Snyk
npm and security, how much do you know about your dependencies?Hack-along, live hacking of a vulnerable Node app, Vulnerabilities from both Open source and written code. Encouraged to download the application and hack along with us.Fixing the issues and an introduction to Snyk with a demo.Open questions.
DevOps.js Conf 2022DevOps.js Conf 2022
76 min
Bring Code Quality and Security to your CI/CD pipeline
In this workshop we will go through all the aspects and stages when integrating your project into Code Quality and Security Ecosystem. We will take a simple web-application as a starting point and create a CI pipeline triggering code quality monitoring for it. We will do a full development cycle starting from coding in the IDE and opening a Pull Request and I will show you how you can control the quality at those stages. At the end of the workshop you will be ready to enable such integration for your own projects.
TestJS Summit 2021TestJS Summit 2021
111 min
JS Security Testing Automation for Developers on Every Build
As a developer, you need to deliver fast, and you simply don't have the time to constantly think about security. Still, if something goes wrong it's your job to fix it, but security testing blocks your automation, creates bottlenecks and just delays releases...but it doesn't have to...

NeuraLegion's developer-first Dynamic Application Security Testing (DAST) scanner enables developers to detect, prioritise and remediate security issues EARLY, on every commit, with NO false positives/alerts, without slowing you down.

Join this workshop to learn different ways developers can access Nexploit & start scanning without leaving the terminal!

We will be going through the set up end-to-end, whilst setting up a pipeline, running security tests and looking at the results.

Table of contents:
- What developer-first DAST (Dynamic Application Security Testing) actually is and how it works
- See where and how a modern, accurate dev-first DAST fits in the CI/CD
- Integrate NeuraLegion's Nexploit scanner with GitHub Actions
- Understand how modern applications, APIs and authentication mechanisms can be tested
- Fork a repo, set up a pipeline, run security tests and look at the results
DevOps.js Conf 2022DevOps.js Conf 2022
32 min
Passwordless Auth to Servers: hands on with ASA
These days, you don't need a separate password for every website you log into. Yet thanks to tech debt and tradition, many DevOps professionals are still wrangling a host of SSH keys to access the servers where we sometimes need to be. With modern OAuth, a single login and second factor to prove your identity are enough to securely get you into every service that you're authorized to access. What if SSHing into servers was that easy? In this workshop, we'll use Okta's Advanced Server Access tool (formerly ScaleFT) to experience one way that the dream of sending SSH keys the way of the password has been realized.
- we'll discuss how ASA works and when it's the right tool for the job- we'll walk through setting up a free trial Okta account to use ASA from, and configuring the ASA gateway and server on Linux servers- we'll then SSH into our hosts with the ASA clients without needing to supply an SSH key from our laptops- we'll review the audit logs of our SSH sessions to examine what commands were run