When conducting a penetration test of a new target API, it is important to do as much recon as you can. One important step to consider is to understand the web technology used to build the API, and what programming language it was written in.
Detecting the programming language of an API can be a difficult task. With so many languages out there, it can be hard to determine which one is being used. What makes it even more difficult is the fact that API management gateways, WAFs, and caching proxying might mask the actual language being used.
While it’s easy to fingerprint websites with chrome extensions like Wappalyzer and online services like BuiltWith, it’s not as easy when trying to figure out what an API was built with.
In this article, I’ll discuss three methods that you can use to detect the programming language of an API. I’ll also provide examples for each method so that you can see how it works!
Why detect the web technology used by an API anyways?
One of the great things about API security testing is the fact so much of it can be done with black box testing. Application programming interfaces typically work in a clear and concise manner and in such an agnostic way you really don’t have to fret about what language it’s in.
At least, right up until you want to exploit the technology the developer chose to abuse the API.
Knowing what programming language is being used allows us to take advantage of potential coding flaws the developers may introduce in the building of the API. It also allows us to tailor our attack payloads specific to the underlying language.
Let’s explore just a few of these.
Common coding flaws you can exploit in APIs
Depending on the language being used, and the framework the API is deployed onto, there are several potential attack vectors you can explore. Let’s explore just a few.
Mishandled serialization and deserialization
When you think about a typical API, it will use objects to pass data around the system. Insecure deserialization may allow you as the attacker to trick the deserializer to execute code of your choosing.
This could come in several forms, including:
- JSON deserialization in REST APIs, especially through Javascript. ie: NodeJS/Express
- PHP object injection from unsafe
unserialize()from params or POST bodies. OWASP covers this threat quite well.
XXE Injection
XML External Entity (XXE) injection is typically something you might see in a SOAP API. However, it doesn’t always have to be. If an API supports the changing of Content-Type to application/xml, you may have an opportunity to abuse that for XXE.
If an API allows the usage of a standard XML parser to process the data, then an injected external entity will be processed on the server side and could lead to information disclosure, LFI, and maybe even escalate to Server Side Request Forgery (SSRF).
Template Injection
Server Side Template Injection (SSTI) occurs when you as the attacker are able to use native template syntax to inject a malicious payload into a template, which is then executed server-side. This allows you to inject arbitrary template directives in order to manipulate the template engine, often enabling you to take complete control of the server.
So how does this help me?
Knowing the programming language of an API you are trying to break has several benefits to help you. A few examples include:
- Knowing the language allows you to focus directory recon on the right file extensions. Why look for PHP endpoints if you know it was written in ASP.NET?
- Knowing the language allows you to better guess the template engine an API may be relying on. Hacktricks has some great insight on how to identify which template engine is in use.
- Knowing which language allows you to zoom into known patterns and antipatterns for deserialization. As an example, if you know it’s an API in Java, you might use ysoserial to generate potential payloads. If it’s PHP, you might use PHP magic methods.
OK, so now you know WHY we should try to figure out what the API is written in, let’s go about DOING it.
Method #1 – Check responses from the API server
Check the HTTP response headers
The HTTP response headers of an API could be a treasure trove of information. In some cases, you might be able to detect the X-Powered-By header which could give you a clue as to what technology is powering the API.
Let me show you how easy this is by checking the GraphQL endpoint at api.spacex.land:
curl -I https://api.spacex.land/graphql/
Notice we can tell their GraphQL API is powered by Express and is running on a Cowboy server. This is a leading indicator that the API may be written in NodeJS.
Here are just a few examples you might find in X-Powered-By headers:
- PHP/x.x.x – the API is written in PHP
- ASP.NET – the API is written in C#
- Express – this API is written in NodeJS
- Next.js – this API is written in NodeJS for use with the React framework
- PleskLin – this API was written in PHP
TIP: Don’t rely on this header on its own. Most API security hardening guidelines include recommendations to remove this header or change it to something that it isn’t.
Other headers that may give you some hints to the web technology and programming language being used include:
- Server – this header will occasionally contain information about the server software being used. For example, Microsoft-IIS/x.x or nginx.
- X-AspNet-Version – this header will be present if the API is written in ASP.NET and can help you determine which version is being used.
- X-AspNetMvc-Version – this header is present when an API is written in ASP.NET MVC.
- Set-Cookie – while it’s not a guarantee, some languages have distinct cookie patterns that may give away what technology is in use. For example, ASP.NET_SessionId, JSESSIONID or PHPSESSID
- X-Runtime – this header is often used in Ruby on Rails applications and can give you a good indication that the API is written in Ruby.
Check the robots.txt file
The robots.txt file is a text file that lives at the root of a website and is used to tell web crawlers which pages they are allowed to index.
In some cases, the robots.txt file will also contain information about the technology being used. For example, if you see “/rails/” in the robots.txt file, that’s a good indication that the API is written in Ruby on Rails.
Check the API documentation
API documentation is typically auto-generated based on the comments that are present in the code. In some cases, these comments will contain information about the technology being used. For example, you might see “Written in Java” or “Powered by Django”.
Doing a simple search for “technology” in the API documentation could give you some clues as to what is powering the API.
Method #2 – Observe and Force Errors
If you can cause the API server to trip up on itself, you may be able to trigger additional stack trace information that may help you determine the language the API is written in.
As an example, you could send an empty payload into an endpoint and see how it responds. Check out how we can detect that crAPI was written in Java simply by causing the signup to fail in its validation:
curl 'http://crapi.apisec.ai/identity/api/auth/signup' -H 'Content-Type: application/json' --data-raw '{}' --insecure -s | jq
As you can see in the response, we detect a BeanPropertyBindingResult. It’s clear to us the API is written in Java using the Spring framework.
Method #3 – Look for anomalous behavior in how the API reacts to data
Detect Language Limits
Detecting language limits can work well when server administrators and/or DevOps keep the defaults in their server configuration. But it isn’t far-fetched to see limits changed from time to time as apps need data to flow differently. In any case, you want to push the data limits for GET and POST operations and see how the API responds.
As an example, PHP limits you to a maximum of 1,000 GET parameters, and a maximum POST size of 8MB. Express (NodeJS) on the other hand has a maximum POST size of 100KB.
The point is if you have indicators of a specific language and you want to check to see, look at the language’s documentation, focusing on the data limits for GET params and POST body size. You might be surprised how quickly you can test this way.
Test Parameter Pollution
HTTP Parameter Pollution (HPP) tests the API’s response to receiving multiple HTTP parameters with the same name; for example, if the parameter name is included in the GET or POST parameters twice.
As an example, imagine this GET request:
https://api.target.domain/users?name=bob&name=aliceNotice how the param name is used twice. How the API handles this could be a leading indicator of the programming language being used. OWASP discusses this in great length here.
Here is a great table OWASP shared that might help:
As you can see, how the API interprets the request may leak what language it was written in. Combined with other methods, it can help you pinpoint this during your recon phase.
Update: Alternative methods from readers
After publishing this article, I received some great suggestions on other indicators to look for.
Some guy on slack (aka Will Whittaker 🤣) had a great suggestion on looking at how the API handles booleans. An API built with a more strongly typed language will generally consume a boolean using true and false values. When it’s not (like in Perl or PHP for example), it might use 1s and 0s.
You can take that further and determine what is going on by how true/false values are used. Are the values strings, or actual JSON-based bools? Are they expecting lower case (ie: true/false in Java, Javascript etc) or capital first letter (ie: True/False in Python)?
All great ways to help isolate what programming language is being used.
Conclusion
Detecting the programming language of an API can be a difficult task, but with these three methods, you should be able to get a good idea of what language is being used. Each method has its own strengths and weaknesses, so you might want to try to use all three together for the most accurate results.
Do you have any other methods you use to detect the programming language of an API? Let me know!
Want to get other tips & tricks on API hacking? Download my free Ultimate Guide to API Hacking Resources PDF and automatically get added to my weekly newsletter.
Happy Hacking!
