In today’s connected world, APIs serve as gateways to critical business functions. They provide access to data, services, and workflows for internal teams, partners, and external users. While this openness supports agility and integration, it also makes APIs attractive targets for attackers.

As software architects, our role goes beyond building functional APIs. We must ensure that they are secure by design. However, security is often added late in the development process. In this article, I share how I strengthened an existing API to protect it from internal misuse and external threats while maintaining performance and usability.

System architecture before API hardening

As-is Architecture

Key components

Consumers: Users or client systems authenticate by using NTLM or Kerberos to access the integration layer.

Integration services (1 and 2): These services act as brokers and handle:

Secure communication that uses mutual TLS (mTLS) or Transport Layer Security (TLS)
Identity propagation through Active Directory credentials
Routing requests through a load balancer to multiple processing nodes

TPMS nodes (TPMS 1–4): Each node includes:

A REST interface exposed through the load balancer
A gRPC interface used internally by the REST layer
Direct access to a shared database

While the REST API enforced authentication and authorization, the gRPC API, intended only for internal use, was accessible on the network.

Core security concerns

The security review revealed several issues that increased the risk of unauthorized access and misuse. The following key concerns highlight where the system’s design relied heavily on network trust and lacked proper access controls.

Externally reachable gRPC interfaces: All TPMS nodes had gRPC interfaces listening on network-accessible ports. Any internal service or user on the same network could call these gRPC methods directly by using the correct protobuf schema and endpoint. This allowed them to bypass authentication, mTLS, and audit checks. The gRPC layer, meant only for trusted internal use, was open to anyone on the network.
No authentication or trust validation: The gRPC layer did not verify who was making the call. There were no checks such as certificates or tokens to confirm identity. The system assumed that all callers were trusted, which left it vulnerable to misuse.
Single enforcement point at the REST layer: Authentication and authorization happened only at the REST layer. If someone bypassed that layer, they could access backend functions directly without any restrictions.
Insider and lateral movement risks: Because gRPC was open to the network, an attacker or compromised system could move within the network and access sensitive components. This created a path for internal threats to spread undetected.

What the root causes revealed

The issues were not random errors but signs of deeper problems:

Assuming the internal network is always safe
Believing that internal components do not need extra protection
Relying on a single layer of security instead of multiple defenses

Addressing the gaps required careful planning rather than quick fixes. Security needs to be part of every stage of system design, not something added later just because a component is “inside” the network.

The hardening approach

Instead of changing core functions or adding complex security layers, we used a simpler and more effective approach called API hardening. This method adds multiple small protections that work together to strengthen security.

As-is Architecture

Goal

Strengthen the API to improve security without affecting performance or usability by:

Allowing the gRPC service to be used only by the REST layer on the same server
Blocking all external access to gRPC and hide it from the network

Implementation steps

Step 1: Bind gRPC ports to localhost

Each gRPC interface was reconfigured to bind only to the loopback address (127.0.0.1). This helped ensure that:

The gRPC service is no longer visible on the network
Only local processes can call it
External traffic is blocked at the socket level

With this change, only the REST API running on the same server could reach the gRPC service, removing the need for extra authentication within gRPC.

Step 2: Firewall and port isolation

At the infrastructure level:

Closed all external gRPC ports in firewalls and security groups
Removed gRPC endpoints from service discovery
Blocked inbound traffic on gRPC ports by using host-level rules (iptables or NACLs)

After these updates, the only externally accessible endpoint was the REST API, protected by the existing load balancer and TLS or mTLS setup.

Key learning

Defense in layers

The changes followed the principle of secure-by-design. Key practices included:

Avoiding trust in network boundaries
Keeping user-facing and system-facing layers separate
Reducing the attack surface
Controlling and monitoring all entry points

Enforcing zero-trust internally

After hardening the system:

Only the REST layer could access gRPC by using secure local communication
Identity and session details were passed explicitly
Direct access to gRPC was both physically and logically blocked
Internal scans confirmed that gRPC ports were no longer exposed

Summary

Securing a system is not just about writing good code. It’s about planning ahead and adding protection at every layer.

Build security into the design: Adding it later often leaves gaps that are difficult to close.
Do not rely on internal trust: Even systems inside the network need strict access control.
Small changes matter: Limiting access and hiding unnecessary components can improve security without reducing usability.
Use multiple layers of defense: If one control fails, others should still protect the system.
Balance security and performance: A secure system can still be fast and efficient.

Strong security comes from clear boundaries, careful design, and thinking like both the user and the attacker. A well-protected system is simple, structured, and ready to face new threats.

Next steps

Strengthen your API security

Now that you learned how to harden your API by restricting access, using local communication, and applying layered security, it is important to keep improving your practices. The following resources can help deepen your understanding and maintain long-term protection.

OWASP API Security Project: Covers common vulnerabilities, risks, and prevention strategies.
Mutual TLS (mTLS) and token-based authentication: Strengthen identity verification and data encryption by using mTLS or token-based methods like OAuth2.
Implement zero-trust internally: Apply “never trust, always verify” principles not just at the perimeter but within your network. This approach supports safe internal API access.
Microservices security best practices: Isolate services, apply network controls, and restrict communication between components to add extra layers of protection.
Logging, observability, and threat detection: Use monitoring tools to detect suspicious activity, configure logging, and analyze API usage in real time.

Final thought

API hardening is an ongoing process, not a one-time task. By using these resources and continuously improving authentication, network isolation, and monitoring, you can build APIs that are secure, resilient, and scalable while maintaining performance and usability.

Strengthen API security with practical hardening techniques

Strengthen API security with practical hardening techniques