API Security Best Practices: Protecting Your Digital Gateways

Application Programming Interfaces (APIs) have become the backbone of modern software architecture, enabling seamless integration between services, mobile applications, and third-party platforms. However, their widespread adoption has made them prime targets for cybercriminals. This comprehensive guide outlines essential API security best practices to safeguard your digital infrastructure.​‌‌​​​​‌‍​‌‌‌​​​​‍​‌‌​‌​​‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​​​‌​‍​‌‌​​‌​‌‍​‌‌‌​​‌‌‍​‌‌‌​‌​​‍​​‌​‌‌​‌‍​‌‌‌​​​​‍​‌‌‌​​‌​‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​​‍​‌‌​‌​​‌‍​‌‌​​​‌‌‍​‌‌​​‌​‌‍​‌‌‌​​‌‌

Understanding API Security Risks

APIs expose application logic and sensitive data, making them attractive attack vectors. Common threats include:

  • Injection attacks (SQL, NoSQL, command injection)
  • Broken authentication and session management
  • Excessive data exposure
  • Insufficient rate limiting
  • Security misconfiguration

1. Implement Strong Authentication and Authorization

OAuth 2.0 and OpenID Connect

Adopt industry-standard protocols like OAuth 2.0 for authorization and OpenID Connect for authentication. Avoid creating custom authentication schemes, as they often contain security flaws.​‌‌​​​​‌‍​‌‌‌​​​​‍​‌‌​‌​​‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​​​‌​‍​‌‌​​‌​‌‍​‌‌‌​​‌‌‍​‌‌‌​‌​​‍​​‌​‌‌​‌‍​‌‌‌​​​​‍​‌‌‌​​‌​‍​‌‌​​​​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​​‍​‌‌​‌​​‌‍​‌‌​​​‌‌‍​‌‌​​‌​‌‍​‌‌‌​​‌‌

JWT Best Practices

When using JSON Web Tokens (JWT):

  • Use strong signing algorithms (RS256, ES256)
  • Keep payload size minimal
  • Implement proper token expiration
  • Validate signatures on every request
  • Use refresh tokens for long-lived sessions

API Keys Management

  • Rotate API keys regularly
  • Use different keys for different environments
  • Implement key expiration policies
  • Monitor key usage patterns for anomalies

2. Validate and Sanitize All Input

Input validation is your first line of defense against injection attacks:

// Example: Strict input validation schema
{
  "username": {
    "type": "string",
    "minLength": 3,
    "maxLength": 30,
    "pattern": "^[a-zA-Z0-9_]+$"
  },
  "email": {
    "type": "string",
    "format": "email"
  }
}
  • Whitelist allowed characters and patterns
  • Validate data types, lengths, and formats
  • Sanitize input before processing
  • Use parameterized queries for database operations
  • Implement Content Security Policy headers

3. Implement Rate Limiting and Throttling

Protect your APIs from abuse and DoS attacks:

  • Set appropriate request limits per client/IP
  • Implement tiered rate limits (free vs. paid tiers)
  • Use sliding window or token bucket algorithms
  • Return proper HTTP 429 status codes when limits exceeded
  • Provide clear rate limit headers (X-RateLimit-Remaining)

4. Encrypt Data in Transit and at Rest

TLS/SSL Requirements

  • Enforce TLS 1.2 or higher
  • Use strong cipher suites
  • Implement HTTP Strict Transport Security (HSTS)
  • Disable SSL certificate validation bypasses
  • Regularly update SSL certificates

Data Encryption

  • Encrypt sensitive data at rest using AES-256
  • Implement field-level encryption for PII
  • Use secure key management systems
  • Rotate encryption keys periodically

5. Implement Proper Error Handling

Information leakage through error messages is a common vulnerability:

  • Return generic error messages to clients
  • Log detailed errors server-side only
  • Avoid exposing stack traces or system details
  • Use structured error response formats
  • Implement consistent HTTP status codes
// Good: Generic error response
{
  "error": "Invalid request",
  "code": "VALIDATION_ERROR"
}

// Bad: Information leakage
{
  "error": "SQL syntax error near 'user' table"
}

6. API Versioning and Deprecation

Maintain backward compatibility while improving security:

  • Use URL versioning (/v1/, /v2/) or header versioning
  • Communicate security updates clearly
  • Provide deprecation timelines
  • Maintain documentation for all versions
  • Force migration from insecure versions

7. Implement API Gateway and Web Application Firewall

Centralize security controls:

  • Use API gateways for unified authentication
  • Implement WAF rules for common attack patterns
  • Enable DDoS protection at the edge
  • Centralize logging and monitoring
  • Implement request/response transformation

8. Logging and Monitoring

Comprehensive visibility is essential:

  • Log all API requests with correlation IDs
  • Monitor for unusual patterns and anomalies
  • Implement real-time alerting
  • Use SIEM tools for log aggregation
  • Regular security audit reviews

Key metrics to monitor:

  • Authentication failure rates
  • Rate limit violations
  • Error rate spikes
  • Unusual traffic patterns
  • Geographic access anomalies

9. Security Testing

Integrate security into your development lifecycle:

  • Perform regular penetration testing
  • Use automated security scanning tools
  • Implement fuzz testing
  • Conduct code reviews with security focus
  • Test third-party API integrations

10. Documentation and Developer Education

Security is only as strong as its weakest link:

  • Document security requirements clearly
  • Provide secure coding guidelines
  • Regular security training for developers
  • Maintain API security checklists
  • Share security incident learnings

Conclusion

API security requires a multi-layered approach combining strong authentication, input validation, encryption, rate limiting, and continuous monitoring. By implementing these best practices, organizations can significantly reduce their attack surface and protect sensitive data while maintaining the flexibility and connectivity that APIs provide.

Regular security assessments, staying updated with emerging threats, and fostering a security-conscious development culture are essential for maintaining robust API security over time.


Need help securing your APIs? Contact the lil.security team for a comprehensive API security assessment.

ELI10: How Hackers Poisoned a Popular GitHub Tool and Stole Thousands of Passwords

TL;DR

  • Hackers secretly changed a popular coding tool used by 23,000+ projects so it would steal passwords and secret keys.
  • 218 projects had their secrets stolen and written where anyone could read them.
  • The trick: the hackers were patient. They spent months sneaking through three different projects before reaching their real target.
  • The fix is simple: always lock your tools to an exact version that can't be secretly swapped out.

What's a Supply Chain Attack?

Imagine you're building with LEGO. You don't make every brick yourself—you trust that the bricks in the box are real LEGO bricks. A supply chain attack is when someone sneaks a fake brick into the box at the factory. It looks normal, but it does something bad when you use it.

Software developers do the same thing. They use building blocks (called "Actions" on GitHub) made by other people to help automate their work. Over 23,000 projects trusted a building block called tj-actions/changed-files to help check which files changed in their code [1][2].

What Did the Hackers Do?

In March 2025, hackers secretly swapped out that trusted building block with a poisoned version [1]. The poisoned version did its normal job—but it also quietly copied every secret password and key it could find, scrambled them in a code (double-base64 encoding), and wrote them into a public log file. That's like writing your house key code on a billboard [2][4].

The stolen secrets included passwords for cloud services (AWS), code-sharing platforms (npm, PyPI), server access keys (SSH), and more [2].

How Did They Pull It Off?

The clever part: the hackers didn't attack their real target directly. According to Wiz Research, they played a long game through three different projects [6]:

  1. Step 1 (November 2024): They tricked a project called SpotBugs into running their code, which let them steal a maintainer's access key.
  2. Step 2 (March 11, 2025): They used that stolen key to sneak into another project called reviewdog/action-setup.
  3. Step 3 (March 14, 2025): From reviewdog, they finally reached tj-actions/changed-files and poisoned every single version of it—from v1 all the way through v45.0.7 [1][4].

It's like breaking into a neighbor's house to steal their key to the office building to get into the vault. One key opened the next door.

How Was It Caught?

A security tool called Harden-Runner, built by StepSecurity, noticed something weird on March 15, 2025—the building block was making network calls it had never made before [5]. The U.S. government's cybersecurity agency (CISA) officially flagged it as a known threat on March 18, 2025, assigning it CVE-2025-30066 with a severity score of 8.6 out of 10 [7][8].

How Do You Stay Safe?

The main lesson is simple: don't trust labels that can be changed. Version tags like @v3 are like sticky notes—anyone with access can peel them off and stick them on something else. Instead, use the exact fingerprint of the code (called a "commit SHA"), which can never be faked or moved [4][10].

Here's what smart teams do:

  • Lock every tool to its exact fingerprint (commit SHA) so no one can swap it out.
  • Give tools only the minimum permissions they need—if a tool only needs to read code, don't give it permission to write.
  • Watch what your tools do at runtime with monitoring tools that catch unexpected behavior [5].
  • Rotate secrets regularly—change your passwords and keys on a schedule so stolen ones expire quickly.

These steps are straightforward, and they go a long way toward protecting what you've built.


FAQ

Q: What is the main security concern covered in this post? A:

Q: Who is affected by this? A:

Q: What should I do right now? A:

Q: Is there a workaround if I can't patch immediately? A:

Q: Where can I learn more? A:

References

[1] Wiz Research, "New GitHub Action Supply Chain Attack: reviewdog/action-setup," Wiz Blog, Mar. 2025. [Online]. Available: https://www.wiz.io/blog/new-github-action-supply-chain-attack-reviewdog-action-setup

[2] BleepingComputer, "GitHub Action supply chain attack exposed secrets in 218 repos," BleepingComputer, Mar. 2025. [Online]. Available: https://www.bleepingcomputer.com/news/security/github-action-supply-chain-attack-exposed-secrets-in-218-repos/

[4] NIST, "CVE-2025-30066 Detail — tj-actions/changed-files," National Vulnerability Database, Mar. 2025. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2025-30066

[5] StepSecurity, "Harden-Runner Detection: tj-actions/changed-files Action Is Compromised," StepSecurity Blog, Mar. 2025. [Online]. Available: https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised

[6] Wiz Research, "Latest GitHub Actions Supply Chain Attack: SpotBugs → reviewdog → tj-actions," Wiz Blog, Mar. 2025. [Online]. Available: https://www.wiz.io/blog/latest-github-actions-supply-chain-attack-spotbugs-reviewdog-tj-actions

[8] CISA, "Supply Chain Compromise of Third-Party GitHub Action CVE-2025-30066," CISA Alerts, Mar. 18, 2025. [Online]. Available: https://www.cisa.gov/news-events/alerts/2025/03/18/supply-chain-compromise-third-party-github-action-cve-2025-30066

[7] NIST, "CVE-2025-30066 Detail," National Vulnerability Database, Mar. 2025. [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2025-30066

[10] Semgrep, "The tj-actions Supply Chain Attack," Semgrep Blog, Mar. 2025. [Online]. Available: https://semgrep.dev/blog/2025/the-tj-actions-supply-chain-attack/


Want help making sure your team's build tools are locked down? We help small and mid-sized businesses audit their CI/CD pipelines and fix exactly these kinds of risks. Book a free consultation →

Ready to strengthen your security?

Talk to lilMONSTER. We assess your risks, build the tools, and stay with you after the engagement ends. No clipboard-and-leave consulting.

Get a Free Consultation