Finding Exposed APIs and Services: A Developer's Guide with ScanSearch

As developers, we’re constantly building and deploying services. Sometimes, in the rush to get things out the door, or through a simple misconfiguration, an internal API or a development environment might accidentally be exposed to the public internet. This isn’t just a theoretical risk; it’s a very real vector for security vulnerabilities.

So, how do we proactively check for these kinds of exposures? Manually scanning IP ranges is tedious and often incomplete. This is where tools designed for internet-wide reconnaissance come in handy. In this article, we’ll explore how to use a service like ScanSearch to identify potentially exposed services, focusing on finding common API endpoints and documentation.

The Problem: Unintended Exposure

Imagine you’ve deployed a new microservice. It’s meant to be behind an API gateway, accessible only internally. But a firewall rule was misconfigured, or a load balancer setting was overlooked, and suddenly, your dev environment’s /api/v1/admin endpoint is directly accessible to anyone on the internet. This isn’t an uncommon scenario, and it can lead to serious data breaches or system compromises.

As developers, it’s beneficial to have a way to quickly check for these kinds of unintended exposures, not just for our own projects but also to understand the broader landscape of internet-facing services.

Introducing ScanSearch

ScanSearch is an internet-wide search engine for network devices, services, and vulnerabilities. Think of it like Google, but for things connected to the internet. It constantly scans and indexes what’s out there, allowing you to query for specific banners, ports, services, or even HTTP responses.

While primarily used by security researchers, developers can leverage ScanSearch to:

• Verify external accessibility: Ensure services intended to be internal remain so.
• Discover common misconfigurations: Search for default credentials, exposed Git repositories, or .env files.
• Identify shadow IT: Find forgotten or unknown internet-facing assets.
• Explore API landscapes: See how common API patterns are exposed.

Let’s dive into some practical examples.

Scenario 1: Finding Exposed Swagger/OpenAPI Docs

Many API frameworks automatically generate documentation endpoints, often at paths like /swagger, /api-docs, or /redoc. If these endpoints are exposed without authentication, they can provide attackers with a complete blueprint of your API, including sensitive endpoint paths, request/response structures, and even authentication mechanisms.

To search for exposed Swagger UI endpoints, we can use ScanSearch to look for specific HTTP response body content that indicates the presence of Swagger UI. A common string is the title tag or a script reference.

Let’s try searching for the HTML title associated with Swagger UI:

http.title: "Swagger UI"

Enter fullscreen mode Exit fullscreen mode

This query will return a list of hosts that have the string “Swagger UI” in their HTTP title. You can further refine this by looking for specific paths or other indicators. For example, to find those specifically on an /api-docs path:

http.title: "Swagger UI" AND http.url: "/api-docs"

Enter fullscreen mode Exit fullscreen mode

This combination is powerful. It allows you to quickly identify services that are not only exposing a web server but specifically exposing their API documentation through a well-known path.

Scenario 2: Discovering Generic API Endpoints

Sometimes, it’s not about a specific documentation page, but just generally looking for common API patterns like /api/v1 or /graphql. While these queries might return a lot of noise, they can sometimes highlight unexpected public-facing services.

Let’s search for servers that respond to common API path patterns:

http.url: "/api/v1/" OR http.url: "/graphql"

Enter fullscreen mode Exit fullscreen mode

This will show you a range of services that have these paths. Clicking on the results often reveals more details, including HTTP headers and the full response body, which can help you determine if it’s a legitimate public API or an accidentally exposed internal one.

Scenario 3: Identifying Development/Staging Environments

Development or staging environments often contain sensitive data, debug information, or unpatched vulnerabilities. If these are accessible from the internet, they become prime targets. We can look for common indicators in HTTP titles or banners.

For example, searching for common keywords in titles:

http.title: "dev environment" OR http.title: "staging server" OR http.title: "test system"

Enter fullscreen mode Exit fullscreen mode

Or even looking for specific default server banners that might indicate a development-focused setup:

http.html: "Welcome to Node.js" AND port: 3000

Enter fullscreen mode Exit fullscreen mode

(Note: The actual content for http.html would be a more specific string from the page, or http.body for the full body content. The example above is illustrative of looking for specific server-side technology indicators combined with a common development port.)

Best Practices for Developers

1. Assume public by default: When deploying anything, assume it’s public until proven otherwise. Double-check firewall rules and load balancer configurations.
2. Authentication and Authorization: Ensure all API endpoints, even internal ones, are protected by robust authentication and authorization mechanisms.
3. Regular Audits: Periodically use tools like ScanSearch to scan your own public IP ranges or domains for unintended exposures.
4. Least Privilege: Configure services with the absolute minimum necessary permissions.
5. Environment Variables: Never hardcode sensitive credentials or API keys. Use environment variables or secure secret management services.

Conclusion

Proactively searching for exposed APIs and services is a critical step in maintaining the security posture of our applications. ScanSearch provides a powerful lens into the internet’s observable surface, allowing developers to identify potential vulnerabilities before malicious actors do. By incorporating such tools into our development and deployment workflows, we can build more secure and resilient systems.

Head over to ScanSearch.net to try out these queries yourself and explore the vast landscape of internet-connected devices and services.