Some of our favorite clients are startups — working directly with founders who
want to build beautiful, user-centric apps on tight timelines and often tighter
budgets. Development in this environment can mean that time on features is
prioritized over protection which is great for an MVP launch but doesn’t hold up
as products begin to scale and attract attention. We experienced this first hand
at a previous startup that we worked at, and have carried that lesson with us
into our current client work. We‘ve been evolving our process to ensure we
secure our backends over the past couple of years, whilst not impacting our
quality or speed for clients. Recently we were lucky enough to have that put to
the test by one of our clients. The company was acquired by a larger
organization who naturally wanted to perform an enterprise level Penetration
Test on the app before dishing out their cash.

![](/evil-pen.jpeg)

In this post, I outline a few GraphQL specific security practices that we can
now say have been battle-tested. It is by no means an exhaustive list but
includes some helpful recipes for securing your API. For a more in-depth
reference, you should refer to
[OWASP](https://www.owasp.org/index.php/Main_Page)

Although most of these points are relevant to any tech stack (or should be
translatable), the tech-stack in question and the one we most commonly use is:

* NodeJS

* GraphQL

* Postgres

* React/React Native

This post assumes knowledge of directives in GraphQL. However, if you’ve not
seen them before it should hopefully still be readable!

*Apollo is a good place to [learn about them](https://www.apollographql.com/docs/graphql-tools/schema-directives.html).*

## Access Control

Access Control, also known as Authorization, is how your application permits
access to resources in your app. Security 101, right, but in anything bigger
than a tiny hobby app, it's easy to leave holes in the bucket.

GraphQL makes it simple and elegant to manage access to resources. Suppose the
following:

```graphql
type Query {
  getMyData: Data @authenticate somePublicData: String
}

type Mutation {
  updateAnItem(id: ID!, name: String!): Item @authenticate
}
```

We authenticate each private field with a custom directive and leave the public
fields directive-free. The danger is that we stop here, call the system ‘secure’
and release. The likelihood is that, without being security conscious, you’ve
gone an implemented the updateAnItem resolver like this:

```js
const updateAnItem = (root, args) => {
  return Item.update({ name: args.name }).where({ id: args.id });
};
```

Although you *have* authenticated generic access to updateAnItem, you haven’t
checked that this user should be allowed to update this item. Granular
authentication must happen at the application logic level, which makes it very
hard to keep track of as your application and team grows. The corrected resolver
could look like:

```js
const updateAnItem = (root, args, ctx) => {
  return Item.update({ name: args.name }).where({ id: args.id, userId: ctx.userId });
};
```

Keep an eye out, educate your team to check for them during code-reviews and
write automated tests to help guide best practice and prevent regressions.

## Anti-Automation

Most applications are under threat from brute-force attacks on passwords,
verification codes or any string that provides some-sort of authorized access to
your system. All it takes is a hacker to execute a script that iterates through
likely combinations until it strikes gold.

The first step to at least partially cover you would be to add error tracking
and alerts to your system. We use [Sentry](https://sentry.io), but there are no
doubt others that do a similar job. Log every error that is thrown and set an
alert for when it occurs at a frequent rate.

However, if you don’t want to be woken to a trillion alerts from Sentry, then
I’d also recommend adding rate-limiting to your vulnerable fields. We’ve built a
small directive library for controlling this, it’s as easy as:

```js
import { createRateLimitDirective } from 'graphql-rate-limit';

const server = new ApolloServer({
  typeDefs: gql`
    type Mutation {
      # Limit to 10 per minute
      login(email: String!, password: String!): String! @rateLimit(max: 10, window: 60000)
    }
  `,
  resolvers: {
    Mutation: {
      login: () => { /* ... */ }
    }
  },
  schemaDirectives: {
    rateLimit: createRateLimitDirective({
      identifyContext: ctx => ctx.req.ip
    })
  }
});
```

More info here:
[https://github.com/teamplanes/graphql-rate-limit](https://github.com/teamplanes/graphql-rate-limit)

## Server-Side Validation Checks

It can be easy to forget that your UI is **not **the only interface to your
system with the ability to make updates and interact with your business logic,
🤦🏻‍♂️. A side-effect of this could be that validation checks are baked into
the client, and not the server. An example being email verification, perhaps the
user **should** be able to log in whilst their email is not verified yet, but they
shouldn’t be able to update their profile or create some data.

Validation checks should be built into your Access-Control, not your UI. So
perhaps you can abstract it out with a withEmailVerified directive or you may
need to implement in your data layer.

```graphql
type Mutation {
  login(email String!, password: String!): String
  updateProfile: Profile @withEmailVerified
}
```

## Verbose Error Messaging

A silly mistake, but an easy one to clear up. In development, it’s handy to
deliver the full error message and stack trace to the client, but doing this in
production could give a hacker enough understanding of the inner workings of
your system to exploit it.

Take the following, you have a simple query that accepts an ID (a string) and
the resolver of getItemById passes the ID into a Postgres query.

```graphql
# Shema
type Query {
  getItemById(id: ID!): Item
}

# Query made by client
query myQuery {
  getItemById(id: "*") {
    id
  }
}
```

You’d end up with an error that could look a little like:

select * from \”items\” where \”id\” = $1 — invalid input syntax for integer: \”
*\”

Although this particular message doesn’t give us much other than telling us that
there is a table ‘items’ and it has a column named ‘id’. You can easily see how
if we had a few other tables referenced, you could build up a picture of the
database structure. An attacker could follow a similar process to piece together
business logic structure or class implementations.

Most GraphQL server libraries allow you to mask or reformat error messages, with
Apollo Server you’d end up with:

```js
new ApolloServer({
  typeDefs,
  resolvers,
  formatError: error => new Error('Internal server error')
});
```

### Summary

Although this is certainly in-exhaustive, hopefully, these points help you in
starting on a journey to securing your GraphQL API. Securing your API is never *‘done’*,
I’d strongly recommend taking a browse through OWASP, a good place to
start is with the [OWASP Node Goat project’s Top 10](http://nodegoat.herokuapp.com/tutorial).

For further reading on GraphQL specific security concepts, [Max
Stoiber](undefined)’s post on [Securing Your GraphQL API from Malicious
Queries](https://blog.apollographql.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b).

How to survive a Penetration Test as a GraphQL developer

The idea of a digital agency Product Manager might seem strange at first glance.
Especially in a tech startup, where the founder has a clear vision of the
product, and a deep understanding of the target user. Not to mention the
authority to create change. But the humble Product Manager is not on the rate
card without good reason. Well, five good reasons to be precise.

## 1. We're here to save you time and money

Ambitious by nature, founders often envisage complex feature sets when
developing or iterating a product. No big surprise given the countless hours
they’ve spent dreaming up their perfect app. As Product Managers, our job is to
challenge you to do less; or, rather, do only what is required to meet your
goals.

By assessing your objectives we’re able to advise on what to build and
how. After all, there is no value in building 'cool feature x' unless we can
prove it’s going to shift the needle. There’s also no value building ‘cool
feature x’ from scratch if a third party option exists that’s going to save you
time and money.

Being a 'yes' person is always the path of least resistance, so,
challenging founders can be an uncomfortable process for Product Managers. But
the success of your business is our top priority, so we will always challenge
your thinking if there’s a chance it will elevate the results.



## 2. We're here to be the voice of your people

Though many founders have spent months if not years investigating what makes
their target audience tick, Product Managers are there to interrogate the
findings, and also discover new ones.

In the long, often drawn-out process of ideation, it’s not uncommon for founders
to develop cognitive bias around their users. For example, a 'confirmation bias'
is where you inadvertently seek out information to support what you already
believe to be true. Do the majority of the users really want to see 'cool
feature x', or just the users you want to listen to? We’re here to help you find
out.

As a business grows, founders also tend to have less time for active user
research, including the response to new features, or any changes to the product
or product context. Product Managers work to fill in those blanks, so the
founder can stay focused on the bigger picture.



## 3. We're here to share our bag of tricks

Whilst most founders possess a clear vision of their product and the desired
output, not all come from a product background. An agency Product Manager brings
the processes and tools to help execute that vision. From payment gateways and
CRMs to analytics and user research, we bring both the experience and expertise
to make problems a thing of the past, and turn your ideas into actualities.


## 4. We're here to do the dirty work

For those familiar with SCRUM parlance, the Product Owner is responsible for
managing the development backlog, ensuring work is correctly scoped, unblocking
developers, overseeing testing and releases, and maximising workflow
improvements. For most Planes projects,  Product Managers will also take on this
less than glamorous but critical role to make sure we are delivering maximum
value to our clients.



## 5. We're here to get the job done

The terms Project Management and Product Management are often confused. While
Product Management supports the founder in defining the what and why of the
product, Project Management deals with the how and when. Product Managers at
Planes wear both hats (but only one at time because wearing two hats looks
ridiculous), so founders can sleep soundly knowing specifications are agreed,
timelines are maintained, risks are managed, resource is planned, and
stakeholders are covered.




As Product Managers, we not only have access to an incredible range of tools and
processes, we also have the nous to use them. And even though the tasks and
requirements may vary from project to project, the Product Manager’s purpose
remains the same: to collaborate closely with our clients to build the best
product possible and, in turn, the best possible business.

Our Insights

We build cool stuff with cool people.

Implementing Fluid Design Using the CSS calc() Function