Most Singapore API security breaches are not sophisticated attacks — they are basic omissions: missing authentication, no rate limiting, verbose error messages. Here is the pre-launch checklist that prevents the most common failures.

A Singapore fintech startup's API was scraped for 3 weeks before anyone noticed. The attacker didn't use any sophisticated technique — they just called the same endpoint 50,000 times with different parameters. No authentication was required. No rate limiting was in place. No monitoring was watching.

They discovered the breach when a competitor launched with suspiciously similar data.

The API had passed a developer review. It worked correctly. It just wasn't secure. These are two different things.

The Singapore Context: Why API Security Matters More Here

Singapore businesses handle data that is particularly attractive to attackers:

  • NRIC numbers (permanent identity identifiers, unlike passwords which can be changed)
  • Financial data and transaction records
  • Healthcare and personal wellness data (under PDPA's sensitive data provisions)
  • Business data with commercial competitive value

Under PDPA, a data breach involving personal information requires notification to the Personal Data Protection Commission (PDPC) if it is likely to cause significant harm. PDPC can impose fines up to S$1 million or 10% of annual Singapore turnover. Security negligence — like having no authentication on an API that handles personal data — is difficult to defend.

The business case for API security is not "it would be nice." It's "the alternative is regulatory exposure, reputational damage, and potential fines."

Authentication: The Non-Negotiable Foundation

Every API endpoint that handles personal data, business data, or any action that should be restricted must require authentication. No exceptions.

API Keys — The simplest approach for machine-to-machine integrations. A key is issued, rotated periodically, and must be included in every API request. Store keys hashed, not in plaintext. Rotate on any suspected compromise. Never put API keys in client-side code (browser JavaScript) where they can be extracted.

JWT (JSON Web Tokens) — The standard for user-authenticated API access. After login, the user receives a signed JWT with an expiry. Every API call includes this token. The server verifies the signature without a database lookup. Tokens expire and must be refreshed.

OAuth 2.0 — For APIs that allow third-party applications to act on behalf of users. The correct choice when you're building an API that external developers will integrate with.

Common mistakes:

  • Returning user data in API responses before verifying the requesting user is authorised to see that specific user's data
  • Using sequential IDs in URLs (api/users/1, api/users/2) — an attacker can enumerate all records
  • Long JWT expiry times without refresh token rotation

Rate Limiting: Preventing Abuse and Scraping

Rate limiting restricts how many API calls a client can make in a given time window. Without it, your API is vulnerable to:

  • Credential stuffing (testing thousands of username/password combinations)
  • Data scraping (systematically extracting all your data)
  • Denial of service (overwhelming your server with requests)

Implementation basics:

  • Set limits per authenticated user (e.g. 100 requests/minute per user)
  • Set lower limits for unauthenticated requests (e.g. 20 requests/minute per IP)
  • Apply stricter limits to sensitive endpoints (login: 5 attempts/minute)
  • Return 429 Too Many Requests with a Retry-After header when limits are hit
  • Use distributed rate limiting (Redis-based) for serverless/multi-instance deployments — in-memory rate limiting breaks when you have more than one server
Security monitoring dashboard
API security failures are most commonly basic omissions — missing authentication, no rate limiting, verbose error messages — not sophisticated attacks.

Input Validation and SQL Injection Prevention

Never trust data that comes from a client. Validate everything.

SQL injection — Passing raw user input to database queries allows attackers to modify or extract data. Prevention: use parameterised queries or an ORM that handles escaping. Never concatenate user input directly into SQL strings.

Input validation — Every field in every API endpoint should have defined type, format, and length constraints. An email field should only accept email format. A phone number field should only accept digits and standard separators. A quantity field should only accept positive integers. Reject and return an error for anything that doesn't match.

Avoid verbose errors in production — Error messages that reveal database table names, file paths, or stack traces help attackers understand your system. Log detailed errors server-side. Return generic messages to clients: "An error occurred. Please try again." Not: "SQL syntax error near users.email at line 14."

HTTPS and Transport Security

All API traffic must be encrypted in transit. HTTPS is not optional for any API that handles personal data.

Beyond the basics:

  • Set HSTS headers to prevent downgrade attacks
  • Use TLS 1.2 or 1.3 — disable older versions (TLS 1.0, 1.1 are insecure)
  • For sensitive integrations, consider certificate pinning

Logging and Monitoring

The fintech startup's breach went undetected for 3 weeks because there was no monitoring. Implement:

Access logging — Every API call: timestamp, endpoint, authenticated user/IP, response code, latency. This is your audit trail for PDPA incident reporting.

Anomaly alerts — Alert when: a single IP makes an unusual number of requests, error rates spike above normal, a new pattern of endpoint access appears, authentication failures exceed a threshold.

Error tracking — Tools like Sentry capture application errors with context. Spikes in specific error types often indicate attack attempts.

The OWASP API Security Top 10

The Open Web Application Security Project publishes the API Security Top 10 — the most common API vulnerabilities. Before any API goes to production in Singapore, walk through this checklist:

  1. Broken Object Level Authorization — can users access other users' data?
  2. Broken Authentication — are authentication mechanisms secure?
  3. Broken Object Property Level Authorization — can users modify fields they shouldn't?
  4. Unrestricted Resource Consumption — is rate limiting in place?
  5. Broken Function Level Authorization — can users access admin functions?
  6. Server-Side Request Forgery — can attackers make your server fetch malicious URLs?
  7. Security Misconfiguration — are default credentials, debug modes, and verbose errors eliminated?
  8. Lack of Protection from Automated Threats — are bots and scrapers rate-limited?
  9. Improper Inventory Management — are old API versions disabled?
  10. Unsafe Consumption of APIs — are third-party API responses validated?

At NICKTUNG, this checklist is part of every API project's pre-launch gate. We don't ship APIs that haven't passed it.

Building an API that will handle Singapore customer data? Talk to us about building it with security from the first line of code rather than bolting it on at the end.