DEV Community: Tristan Kalos

Express.js Security Best Practices

Tristan Kalos — Wed, 22 Nov 2023 10:55:17 +0000

Express.js is a fast, unopinionated, minimalist web framework for Node.js. It's widely used to build web applications, and as such, ensuring that applications built with Express.js are secure is paramount. Here, we’ll walk through ten best practices to help you strengthen the security of your Express.js applications.

1. Use Helmet

Helmet helps secure your Express apps by setting various HTTP headers. It's not a silver bullet, but it can help protect against some well-known web vulnerabilities by setting headers like X-Content-Type-Options, X-DNS-Prefetch-Control, and others.

const helmet = require('helmet');
const app = require('express')();

app.use(helmet());

2. Keep Dependencies Updated

Vulnerabilities in software are discovered regularly. Using outdated packages can leave you susceptible to these issues. Use tools like npm audit or Snyk to identify and update vulnerable dependencies.

npm audit fix

3. Implement Rate Limiting

Rate limiting helps to prevent brute-force attacks by limiting the number of requests users can make within a certain timeframe. For Express.js, you can use the express-rate-limit middleware.

const rateLimit = require('express-rate-limit');

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
});

app.use(limiter);

4. Sanitize Input

Input sanitization helps prevent injection attacks. It's important to never trust user input and always to sanitize and validate it before processing.

const express = require('express');
const app = express();
const { body, validationResult } = require('express-validator');

app.post('/user',
  body('username').isAlphanumeric(),
  body('email').isEmail(),
  (req, res) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
      return res.status(400).json({ errors: errors.array() });
    }

    // Proceed with handling request
});

5. Use HTTPS

HTTP traffic is unencrypted, making it susceptible to interception and alteration. Use HTTPS to encrypt data in transit. With Express.js, you can use Node's https module in conjunction with fs to read SSL/TLS certificates.

const https = require('https');
const fs = require('fs');
const app = require('express')();

const options = {
  key: fs.readFileSync('key.pem'),
  cert: fs.readFileSync('cert.pem')
};

https.createServer(options, app).listen(443);

6. Handle Errors Properly

Express.js has default error handling, but it's recommended to implement a custom error handling middleware to catch and properly manage errors.

app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).send('Something broke!');
});

7. Use Cookies Securely

If you’re using cookies for session management, use secure + httpOnly flags to prevent client-side scripts from accessing the cookie.

const session = require('express-session');

app.use(session({
  secret: 'your-secret',
  cookie: {
    secure: true,
    httpOnly: true,
  },
  // other configuration
}));

8. Avoid Revealing Stack Traces

Express.js, by default, will expose a stack trace to the client on an error. Turn off stack traces in production to avoid revealing too much.

if (app.get('env') === 'production') {
  app.use((err, req, res, next) => {
    res.status(500).send('Server Error');
  });
}

9. Secure File Uploads

If your application deals with file uploads, ensure you check the file type, limit the size, and scan for malware.

const multer = require('multer');
const upload = multer({
  dest: 'uploads/',
  limits: { fileSize: 1000000 },
  fileFilter: (req, file, callback) => {
    if (!file.originalname.match(/\.(jpg|jpeg|png|gif)$/)) {
      return callback(new Error('Only image files are allowed!'), false);
    }
    callback(null, true);
  }
});

10. Authenticate & Authorize

Always implement strong authentication and authorization checks. Tools like Passport.js can help you manage these securely.

const passport = require('passport');
const LocalStrategy = require('passport-local').Strategy;

passport.use(new LocalStrategy((username, password, done) => {
  // Implement your verification logic
}));

When you follow these best practices, you're not only protecting your application but also safeguarding users' data and trust in your application. Remember, security is an ongoing effort and requires regular code reviews, monitoring, and updates to stay ahead of potential threats 😉

Introducing APIrank.dev algorithm update - a better benchmark of 7000+ Public APIs on the internet

Tristan Kalos — Sat, 15 Apr 2023 20:38:42 +0000

tl;dr we (Escape) have updated our ranking of 7000+ public APIs according to security, performance, reliability, and design criteria. The results are public on APIrank.dev. You can also request to index your own API for free and see how it compares to others.

APIrank is a powerful tool that ranks over 7000 public APIs based on security, performance, reliability, and design criteria. And now, with our latest update, we've made it even better. We've improved the weights of the ranking parameters and added additional data sources, like domain reputation, for more accurate results.

By using APIrank, developers can easily find and pick the right external APIs for their projects. Our platform provides in-depth insights about the security, reliability, performance, and ease of use of the APIs, so you can make informed decisions and avoid any potential headaches down the road.

And the best part? You can index your own API for free and see how it stacks up against the competition.

Ready to get started? Head over to APIrank.dev to learn more and try it out for yourself. And if you need any help along the way, be sure to check out our blog for more information and resources. Happy coding! 🤖

Getting started with Postman for GraphQL

Tristan Kalos — Fri, 07 Apr 2023 20:21:39 +0000

This is an article by @nohehf that also have been published on our blog: https://escape.tech/blog/getting-started-with-postman-graphql/

If you're building an API, you need to have tools to query it. Postman is the reference for this, allowing you to create and send requests to your endpoints and so much more.

Postman has loads of built-in parameters and features, such as custom cookies, environment variables, scripting, testing, and exporting requests to HTTP clients (curl, fetch, python, axios...). Postman also allows you to share and collaborate on your requests collections, making it a go-to tool for many tech enterprises. It also ships with a powerful mocking engine, allowing developers to design their APIs directly in Postman before implementing them.

In this guide, you'll learn the basics of Postman for GraphQL APIs, so you can quickly start using it to create and debug yours.

To get started, get Postman here: https://www.postman.com/downloads/

Note: if you already use Postman for REST and only want to see the GraphQL part, head to #🕸using-postman-with-graphql-apis

🧠 Postman general concepts

Requests

As Postman is an API client, HTTP requests are its fundamental building block. Create a request by with "new" -> "HTTP request"

The top bar allows you to set the request mode (GET, POST, PUT, ...) and its URL:

Below you'll find several tabs:

Params are REST query params of URLs:?key=value, those are useless for GraphQL
Authorization allows you to define multiple types of Auth such as Bearer Token, API key, etc.
Headers are self-explanatory
Body is the part that interests us for GraphQL, and I'll detail it in the next paragraph
Pre-request Script and Tests are more advanced functionalities that I'll cover in an advanced guide.

And last but not least, remember to save your requests! (ctrl + s or the "save" button).

Collection

If you try to save your request, a prompt will ask you to choose a collection. Postman collections are just groups of recommendations. Try to edit and save your request in a collection!

Workspace

The workspace is like a group of collections & requests, but with superpowers. You can share workspaces (publicly or privately with your team), have scoped environments, variables, etc. You can see your current workspace name and its "parts" on the left tab:

🕸 Using Postman with GraphQL APIs

Back to business: fortunately, Postman has built-in full support for GraphQL! 🎉Let's take a quick tour of the capabilities by exploring the Rick and Morty API. To get started, create a new HTTP request in Postman. Set the request mode to POST and the URL to https://rickandmortyapi.com/graphql. Now; in the body section, select GraphQL. You should end up with something like this:

The cool thing about Postman is that it auto-fetches your endpoint's schema, as you can see with the green "Schema Fetched." indication. That allows auto-completion of your queries with typing and so on. Start typing a query with:

query {

}

Now, if you hit [⌃ + space] or [ctrl + space], you should see auto-suggestions of what you can query in the API:

Let's say we want to get the characters of the show, simply type character inside of the query, and Postman will quickly tell you what your request is missing, thanks to the schema:

So here we can see what's the problem:

Subfields: character is an object type, so we need to specify which fields of the character we want to get.
Argument: the character has to be selected with its id.

Let's correct the request:

But you can see that you still need to select subfields, same as before, to see what's valid just hit [⌃ + space] or [ctrl + space] to get suggestions of available fields:

We can complete and send it. You can see that we got the desired results:

We also have object fields that need their subfields; see origin here.

As a last detail, let's use variables:

This request will get you the same result. Still, its format is way cleaner, and the variable fields can be bound to postman variables and scripted this way, allowing you to write super powerful tests and routines, which I'll cover in the following guide!

🚀 Escape will gain you hours

What if I told you that all the heavy work of crafting requests for your GraphQL API could be fully automated?

Escape automatically tests the security, performance a reliability of your GraphQL API in a few seconds.

But the cool thing is that it is based on a powerful feedback-driven API exploration algorithm that is able to generate legitimate requests on your API before fuzzing them for security purposes.

And the cool stuff is that in addition to be able to find and fix your API bugs, you can easily reproduce them thourgh the autogenerated Postman Collection, while exploring all your API.

👉 Try it yourself fo free in 1 minute! It does not require any configuration ;)

Conclusion

By now, you should be able to query your GraphQL API using Postman, and this will help you a lot in your development process, trust me!

But as I said, Postman can do a lot more than what I've covered here: scripting, testing, environment setup, exports... I'll cover those advanced and super powerful concepts in the following article, so stay tuned to become a Postman master! 😎

Demystifying GraphQL Security: A Comprehensive Guide to Introspection

Tristan Kalos — Thu, 30 Mar 2023 18:00:33 +0000

This post by Antoine is easier to read on our blog

Whether or not to disable introspection has been a common debate among GraphQL developers since its inception. In this blog post, we will explain why completely disabling introspection is not necessary and why it can be counterproductive.

// Detect dark theme var iframe = document.getElementById('tweet-1221971611953369088-742'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1221971611953369088&theme=dark" }

Marc-André Giroux, Author of Production Ready GraphQL

Why is introspection useful?

What is introspection?

Firstly, it's essential to understand what Introspection is in GraphQL. It is the ability to provide metadata about its schema, including types, fields, and directives. It allows developers to explore the API structure and understand the available data.

The simplest way to know if your introspection is open is to fetch it yourself!

curl --location 'https://example.com/graphql' \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '{"query":"query IntrospectionQuery { __schema { queryType { name } mutationType { name } subscriptionType { name } types { ...FullType } directives { name description locations args { ...InputValue } } } } fragment FullType on __Type { kind name description fields(includeDeprecated: true) { name description args { ...InputValue } type { ...TypeRef } isDeprecated deprecationReason } inputFields { ...InputValue } interfaces { ...TypeRef } enumValues(includeDeprecated: true) { name description isDeprecated deprecationReason } possibleTypes { ...TypeRef } } fragment InputValue on __InputValue { name description type { ...TypeRef } defaultValue } fragment TypeRef on __Type { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name ofType { kind name } } } } } } } }","variables":{}}' \ > introspection.json

The curl introspection command

An essential feature for productivity and flexibility

Introspection is a handy feature for front-end and client developers. In particular, one of the most significant advantages of GraphQL is its ability to allow them to request only the data they need. Introspection plays a crucial role in this process by enabling them to discover and understand the available types and fields in the schema.

By disabling introspection, you're essentially taking away a valuable tool that developers can use to improve their productivity and make better-informed decisions about how to structure their queries.

Moreover, Introspection can be a valuable tool for API documentation and discovery. By disabling it in production, you might need to invest additional resources in maintaining separate documentation and keeping it up-to-date. This can increase the complexity of your API maintenance process and potentially lead to inconsistencies between the actual schema and the documentation.

Is introspection really a security concern?

It seems like a potential security risk

The main argument for disabling introspection is that it can be a security risk. By allowing introspection, malicious actors can exploit this information to craft targeted attacks against your application. In particular, it can potentially expose additional entry points, such as hidden or undocumented operations that might not be as secure as the rest of your application.

It can also be a performance issue. When a GraphQL server receives an introspection query, it must traverse the entire schema and gather metadata, which can be time-consuming and resource-intensive.

Where there's a will; there's a way

At that point, it might seem obvious to disable introspection for security purposes. The problem is that disabling it is just a "false good idea". There is always a simple way to find your schema and craft malicious requests against your GraphQL API.

Field suggestion leaks your schema

Most GraphQL engines have a feature called Field Suggestion. When the server receives a query with invalid fields, it will respond with an error message indicating that the requested field does not exist.

However, this error message also contains information about fields with similar names that do exist within the schema. This GraphQL feature is called Field Suggestion.

{
  "errors": [
    {
      "message": "Cannot query field \"space\" on type \"Query\". Did you mean \"escape\"?",
      "locations": [
        {
          "line": 1,
          "column": 5
        }
      ],
      "extensions": {
        "code": "GRAPHQL-VALIDATION-FAILED"
      }
    }
  ]
}

Field suggestion in GraphQL

This feature can be abused: by sending random field names in a query and gathering the suggestions that the servers send back, one can build back the complete GraphQL Schema! This is an attack called Field Fuzzing.

Clairvoyance is an open-source tool created by Nikita Stupin and maintained by Escape that allows developers to retrieve GraphQL introspection data even when disabled using Field Fuzzing.

By analyzing these error messages, Clairvoyance can determine the structure of the schema and retrieve the necessary introspection data.

On Apollo and Yoga servers, you can easily disable Field Suggestion using our free, open-source tool GraphQL Armor.

The frontend knows everything.

Obviously, it is possible to recreate the introspection from the traffic generated by a front-end. This means that even if you disable introspection, a determined attacker could still gain access to the schema information by navigating to your application's website.
My introspection is only enabled on staging

Do you think keeping your introspection open on staging makes your production more secure?

Most of the time, we notice that if your production endpoint is available on https://graphql.example.com/, your staging environment is accessible through https://staging.graphql.example.com/. In that case, getting the introspection of your staging is a no-brainer.

Let's say you tried to hide your staging environment on a random URL. At Escape, we developed open-source software to find any GraphQL endpoint related to your main application.

Using subdomain enumeration, web crawling, and brute forcing, Goctopus can find any of your GraphQL endpoints and know whether introspection or field suggestions are enabled on each of them.

We use Goctopus in our own platform, Escape, to index all our customer's exposed GraphQL Endpoints. We discovered that a surprisingly high amount of organizations have their staging and development environment open, with introspection activated.

Conclusion: don't trade productivity against obscurity

At Escape, we believe in security by obscurity, and thus we advise not to disable introspection.

You can keep your introspection enabled: Completely disabling introspection doesn't actually make your server more secure; it just makes it harder for developers to do their jobs.

Optionally, implement role-based access control: If you still don't fill confident in letting your introspection open to the world, you can configure your GraphQL server to enable introspection only for specific user roles, such as administrator or developers, ensuring the feature is accessible only to trusted users. See more details in our documentation.

Ultimately, deciding to disable introspection in production depends on your specific use case and requirements. Ensure you provide your developers with the best experience while maintaining a robust application.

The State of Public APIs 2023

Tristan Kalos — Thu, 23 Mar 2023 17:02:16 +0000

tl;dr we (Escape) scanned 6056+ public APIs on the internet with our in-house feedback driven exploration tech and ranked them using security, performance, reliability, and design criteria. We decided to analyze the resulting data and produce a full featured report: The State of Public APIs 2023

Why build this report? 🤔

Two weeks ago, we released apirank.dev, the result of extensive research on public APIs on the internet, conducted at an unprecedented scale using our feedback-driven API exploration technology. You can read more about this in our original APIRank post.

But we quickly realized that the data we gathered for ranking APIs could also be used to establish a benchmark of the current state of Public APIs in the wild.

Thus, we compiled this dataset into a full-featured report that analyzes the performance, reliability, design, and security of the APIs we scanned.

To our knowledge, this is one of the first of its kind study about the quality of APIs, mostly because of its scale and the depth of the data we gathered.

What are the properties we analyzed? 🎯

Since the data we used for creating the report comes from APIRank.dev, we used similar properties to those in our original study:

Security
Performance
Reliability
Design
Popularity

Results 🏅

The full results can be found on The State of Public APIs 2023

We discovered that while public APIs are getting more and more documented, significant improvement in the industry can still be made regarding documentation quality, response reliability, and especially security.

We hope to see more studies of this kind to be conducted to observe how those tendencies evolve in the future.

APIRank.dev - we crawled and ranked all public APIs on the internet 🔭

Tristan Kalos — Tue, 21 Mar 2023 17:07:57 +0000

tl;dr we (Escape) scanned 3000+ public APIs on the internet with our in-house feedback driven exploration tech and ranked them using security, performance, reliability, and design criteria. The results are public on APIrank.dev. You can also request to index your own API for free and see how it compares to others.

Why APIrank? 🤔

During a YC meetup I spoke with a fellow founder that told me how hard it was to pick the right external APIs to use within your own projects.

It's true that as developers and hackers, we rely more on external services for building our products.

We interact with those vendors' services through their public APIs, which often become a central part of our stacks.

Yet, no good resource existed to compare the quality of similar vendors' public APIs to help engineering/product teams pick the right provider.

What if there was a website that would help you compare the performance, reliability, security, and design of different vendors' public APIs?

Well, say hello to apirank.dev!

Why is ranking public APIs hard? 🥵

Automating the audit of public APIs is a very hard problem. First, we needed to find all the public APIs and their specifications - mostly OpenAPI files.

We used several different strategies to fetch OpenAPI specifications:

Crawl API repositories like apis.guru
Crawl github for openapi.json and openapi.yaml files
A cool google dork

Those strategies enabled us to gather around ~20.000 OpenAPIs specs.

Then lies the hard part of the problem:

We want to dynamically evaluate the security, performance, and reliability of those APIs.

But APIs take parameters that are tightly coupled to the underlying business logic.

A naive automated would also not work: putting random data in parameters would likely not pass the API's validation layer, thus giving us little insight into the real API behavior.

Manually creating tests for each API is also not sustainable: it would take years for our 10-people team. We needed to do it in an automated way.

Fortunately, our main R&D efforts at Escape aimed to generate legitimate traffic against any API efficiently.

That's how we developed Feedback-Driven API Exploration, a new technique that quickly asses the underlying business logic of an API by analyzing responses and dependencies between requests. (We did a more in-depth blog post about it)

We originally developed this technology for advanced API security testing. But from there, it was super easy also to test the performance and the reliability of APIs.

How we ranked APIs 1️⃣0️⃣0️⃣

Now that we have a scalable way to gather exciting data from public APIs, we need to find a way to rank them. And this ranking should be meaningful to developers when choosing their APIs.

We decided to rank APIs using the following five criteria:

Security
Performance
Reliability
Design
Popularity

An API's security score is computed as the combination of two sub-scores: the number of OWASP top 10 vulnerabilities and the number of personally identifiable information (PII) leaks detected by our scanner.

The performance score is derived from the median response time of the API, sometimes referred to as p50.

The reliability score is derived from the number of inconsistent server responses, either server errors or non-conforming return values.

The design score reflects the quality of the specification file. Having a high-quality specification file (with up-to-date types and examples) helps developers understand the API and tools to produce relevant documentation.

The popularity score is computed from the number of references to the API found online.

If you are curious about your API's performance, you can ask us to index your API on APIrank.dev!

Our ask 😃

Ranking all public APIs on the internet is a massive project, and we would gladly welcome help from the community!

You can help us by:

Giving your feedback on our ranking criteria and proposing new ones
Sending us Public APIs to add to our index
Sharing your favorite API's score on social media

Releasing OpenAPI.security, a free tool to quickly check the security of any Swagger / OpenAPI-based API

Tristan Kalos — Sat, 11 Feb 2023 18:46:43 +0000

tl;dr we released openapi.security, an online tool that performs a dozen of security tests on any given openapi/swagger-based API, with no signup or email required

Our team at Escape is mainly focused on securing GraphQL APIs. For this, we developed a new approach called Feedback driven API Exploration, basically inferring the right security tests cases to run using the specification and a carefully crafted in house graph traversal algorithm. - We published a more in depth review of this algorithm in another post.

At Escape, we often organise internal hackathons. It's a way to learn new things, but also to experiment with our internal tools and discover new applications. This time, we wondered if our Feedback Driven Exploration could be applied to good old REST APIs as well and ended up creating OpenAPI.security.

The concept is simple: anybody can enter an OpenAPI / Swagger spec, and openapi.security will run a bunch of security tests on it and give back a report. It's designed to be fast and smart in the way it analyzes input specs.

Since it worked quite well we wanted to share it with the community as well. (NB It's a side project for now)

Graphman: generate a postman collection for any GraphQL endpoint

Tristan Kalos — Tue, 09 Aug 2022 12:00:49 +0000

tl;dr we released github.com/Escape-Technologies/graphman, a free and open source tool that generates a Postman collection for any GraphQL endpoint in seconds 👨‍🚀

We use GraphQL with Postman a lot in our team. GraphQL is pretty verbose and we found it quite painful to write all the queries by hand when interacting with any new endpoint.

So we created Graphman, a tiny utility that uses GraphQL's introspection capability to generate a full Postman collection for any GraphQL endpoint.

Happy to release this to the community as a free and open source dev tool 🤟

Link to the repo: https://github.com/Escape-Technologies/graphman

If you use GraphQL, feel free to help us by staring and contributing 🤩

GraphQL Armor: A middleware to make your GraphQL endpoints secure

Tristan Kalos — Fri, 05 Aug 2022 12:06:00 +0000

tl;dr we released github.com/Escape-Technologies/graphql-armor, a developer friendly, free and open source middleware that adds a security layer to any js-based GraphQL server.

"GraphQL is less secure than most REST APIs"

This is something we have heard a lot since GraphQL's inception in 2015.

Our security research team confirmed this when spending a year on evaluating security in the GraphQL ecosystem. (I even gave a talk about the results at GraphQL SF 2022)

We decided the GraphQL ecosystem deserved to be more secure and created GraphQL Armor, a developer friendly middleware that quickly adds a security layer to any js-based GraphQL server.

Out-of-the-box, you get protection against:

Bruteforcing
Query complexity attacks (Depth, Width, cyclomatic complexity)
Information Disclosure (Schema leaks)

But more is to come, we are adding protection against new attacks every week 😎

Link to the repo: https://github.com/Escape-Technologies/graphql-armor

If you use GraphQL, feel free to help us by staring and contributing 🤩