Securing GraphQL Endpoints in the Full Development Lifecycle

I have been working on software development for a year, and I noticed that the essential thing in this process is getting results, not the development process itself. During development, developers usually integrate many different technologies into the project. For example, let's say we are developing a graphQL application. The first technology we need to incorporate into this application is the library that the developer will use to build the graphQL endpoint. Another technology that the developers might use is the database library that will be used to store the information used in the graphQL endpoint.

The problem is because of this focus on the result and not the process, and due to the integration of many technologies in the project, the security of the developed program is becoming a significant concern.

Regarding software security, most developers believe that the safety of their program comes from writing clean lines of code, checking every possible condition, and having good error handling. However, the truth is far from that; securing the code starts from the beginning. Making sure that your code is secure can be divided into four parts.

Software Component Analysis (SCA)

The first part of securing any code is software component analysis. SCA inspects package files for vulnerabilities by crossing these packages by the NVD (National Vulnerability Database).

This is very important since importing packages with vulnerable functions is very dangerous. Even if the programmer wrote his entire code securely, there would always be vulnerable functions that he isn't aware of. Many tools can be used to perform the SCA; some are paid tools like Snyk and Mend, and some are open-source tools like safety.

To understand more about how to integrate SCA into the CI/CD process, you can visit this blog.

Detecting Insecure Code

After ensuring that all the functions, libraries, and packages are imported, it is time to check if the actual code is secure. As known, some of the most serious security vulnerabilities exist due to using incorrect practices. For example, let us consider the source of SQL injections in python. Consider the following python function.

As you can see, although the code above does what it needs to do, which is get the transactions that are sent from user1 to user2, since we didn't use a parameterized query for the variable user_id_second like we used for user_id_first, this function is vulnerable to SQL injection.

To be able to fix this, we need to use tools like semgrep. To understand what semgrep does and how to integrate semgrep to the CI/CD, you can read all you need to know from this blog.

Dynamic Testing and Scanning of the GraphQL Application

Even after writing the graphQL application and deploying it, securing it doesn't stop there. After launching the graphQL application, it is time to check for vulnerabilities by scanning the applications and doing some dynamic tests. There are many tools to do so, but the best tool I know is Escape.

Escape is a dynamic graphQL API security testing tool that will find almost all vulnerabilities quickly and easily. All that needs to be done is to input the URL to the graphQL endpoint, and it will find all the vulnerabilities that can be found in the graphQL API. You can see the scan result on a dummy graphQL endpoint below.

After finishing the scan, you can see all the vulnerabilities found, a score of how secure the endpoint is, and all the sensitive information that might be leaked from the database. In addition, the tool will also give you a comprehensive list of all the remediation you can do to secure the application from the vulnerabilities listed.

Runtime Protection

After doing all this, you might think you are secure. NOOOO, this is not the case. It would help if you made sure that the server on which the graphQL application is running is 100% safe and that there is no misconfiguration. Not only that, you need to check that it remains secure no matter what changes you make to the application. To keep your application constantly safe, regardless of the engine you are using to generate the graphQL endpoint, there is a tool called graphQL armor.

Plugging graphQL armor into your application will secure the misconfiguration and stop the DOS.

You can check out this excellent blog to understand how to use graphQL armor.

Conclusion

From the four steps seen above, I think it is pretty obvious that securing a graphQL endpoint is a huge pain. Some of you might think that adding all this to your CI/CD is not worth it; however, in a world where everyone is connected to one another and where everything is accessible with a click of a button, privacy became something that all consumers desire, and with this guide, is something you can quickly provide.

Food for thoughts

💡 Wanna learn about GraphQL testing? Read our blog article "How to test your GraphQL API?".