Love Your APIs: Secure Every Pull Request with StackHawk

The Heartbeat of Modern Applications: APIs

At this point I think we all know it, or can at least feel it, APIs power virtually every application we use, acting as the essential communication channels between different software components. From mobile apps and cloud services to enterprise systems, APIs—including REST, GraphQL, and SOAP—make seamless interactions possible. Yet, their widespread adoption also exposes businesses to significant security vulnerabilities. Ensuring robust security across these interfaces is critical, particularly in today’s landscape of frequent data breaches and evolving cyber threats.

At StackHawk, we love APIs:, GraphQL, SOAP and our own REST API that supports our platform. And we make sure to regularly scan them all.

StackHawk loves REST and GraphQL and SOAP

For our true blue and stalwart suitor (the simple API backed by a DB setup) we can two-step with them at the local sock hop (what’s a two-step and sock hop? who are these references even intended for?). Scanning a GraphQL app with HawkScan in Kubernetes is a snap. Just throw your sweetheart (HawkScan) in your sidecar (your sidecar is a Kubernetes sidecar but also works as a metaphor) and drive (probably to the local malt shop or something).

Here’s an example of our manifest.

apiVersion: v1
kind: Pod
spec:
 volumes:
   - name: conf-dir
     configMap:
       name: configuration-dir
   - name: script-authentication-dir
     configMap:
       name: configuration-script-authentication
 containers:
   - name: hawkscan
     image: stackhawk/hawkscan:latest
       - name: API_KEY
         value: hawk.xxxxxxx.xx
       - name: APPLICATION_ID
         value: xXXxxxX-xxxx-xxxx-xxxx-XxXxXX
       - name: REPO_DIR
         value: /conf

     volumeMounts:
       - name: conf-dir
         mountPath: /conf
       - name: script-authentication-dir
         mountPath: /conf/scripts/authentication
   - name: vulny-app
     image: my-vulny-app/vuln-graphql-api

We’ve loaded our stackhawk.yml and custom authentication scripts in our /conf directory that we’ve volume mounted onto our pod with a config map. We use this setup against GraphQL, SOAP and REST.

We test each release of HawkScan against our vulny apps (look them up here and pick your poison https://github.com/kaakaww ) to ensure it catches all the vulnerabilities (security exploit vulnerabilities not ones related to emotional maturity).

But what happens when your application doesn’t look like a single container and looks more like this.

On top of that, you made a great choice to run gRPC, but you can’t HawkScan gRPC.

We look like this too

To avoid corrupting staging and production data, we create an environment to test against a PR, as ephemeral as a kiss blown in the wind. Our traditional REST API is backed by microservices with gRPC communication. So to get meaningful scan results from our scanner we need all those microservices and their supporting databases (hopefully with some data) running.

We heart Docker

On each PR, we launch our API and every one of its dependencies in Docker containers and scan it. And if you’re using GitHub Actions you can throw HawkScan Action into your pipeline…look at how cute she is: https://github.com/stackhawk/hawkscan-action . Just a few lines of configurations in your workflow brings it in:

- name: RunHawkScan
    id: run-hawkscan
    uses: stackhawk/hawkscan-action@main
    with:
     apiKey: ${{secrets.HAWK_API_KEY}}

So we spin up each of our services in their own Docker container and our API and scan them with our HawkScanner. But that’s a lot of containers…I don’t know about you but the majority of our gRPC services are backed by databases. So we’re spinning up at least two containers for each service and that’s a lot of containers…well at least 2 times the amount of containers as before.

But we’ve had our eye on Kubernetes, he’s cute

We could just as easily spin up a bunch of pods in Kubernetes with all their dependencies and launch HawkScan as a job or pod to scan the service.

apiVersion: batch/v1
kind: Job
spec:
   spec:
     volumes:
      - name: conf-dir
        configMap:
        name: configuration-dir
     containers:
       - name: hawkscan
         image: stackhawk/hawkscan
     volumeMounts:
       - name: conf-dir
         mountPath: /conf

This feels like scanning a monolith. Don’t we love microservices and tiny testing and shifting left? I want to get back to our true blue suitor.

Conclusion

Securing APIs is a critical, ongoing process, essential for safeguarding user data, maintaining customer trust, and protecting your organization’s reputation. By incorporating StackHawk into your development and security practices, you strengthen your API defenses proactively and continuously.

Ready to love your APIs?

• Start your free StackHawk trial and experience effortless, comprehensive API security testing.
• Schedule a demo to see StackHawk’s powerful features in action.

Give your APIs the protection and care they deserve with StackHawk—because secure APIs are happy APIs.