The API is the heart of every mobile application and every SaaS system. Period. Through that single channel flow user data, payments and the entire business logic. At Web Systems we secure it from the first sprint – and this is not about compliance (though that too), but about plain economics. Patching a hole in a live product costs many times more than thinking security through at the start. Attacks on APIs grow by double digits year over year, and companies often learn about a breach weeks later. In this guide I share experience from nearly two decades of designing and maintaining systems – from startup MVPs to large B2B platforms handling thousands of requests per second.
Spis treści
The most common API attack vectors in mobile and SaaS applications
The OWASP API Security Top 10 list is a good starting point for an audit, but the real threats go further. Broken Object Level Authorization (BOLA) – still number one among exploited vulnerabilities. The attacker swaps the resource identifier in a request and simply sees another user’s data. Broken Authentication allows a session or token to be hijacked without knowing the password. Mass Assignment – overwriting fields the endpoint should not accept. These three categories account for most of the incidents we detect during audits at Web Systems.
The attack surface looks completely different in a mobile app and in classic SaaS. A mobile client can be decompiled, put behind a proxy, and API keys hardcoded in the binary can be extracted. A SaaS platform with a multi-tenant architecture, on the other hand, is mainly exposed to data leaking between accounts. A missing tenant_id filter in a single database query is enough for customer A to see customer B’s invoices. I have tested this many times – both scenarios require different defense strategies, even though the fundamentals are shared.
- No rate limiting – allows brute-forcing tokens and enumerating resources by iterating through identifiers
- Tokens passed in the URL – they end up in server logs, browser history and Referer headers
- Excessive endpoint permissions – the endpoint returns more data than the client needs, making reconnaissance easier
- No schema validation – the API accepts arbitrary fields in JSON, opening the door to mass assignment
- Inconsistent authentication mechanisms – some endpoints protected by a token, others accessible without authentication
Seemingly minor oversights can cause quite a mess. One of the projects we took over for maintenance had an admin endpoint available without authorization. What “protected” it? An undocumented prefix in the URL path. Seriously. Another system returned full user objects in list responses – including hashed passwords. Such mistakes do not come from bad intentions. They come from the lack of a systematic approach to API security at the design stage.
Authentication and authorization – the foundation of a secure API
OAuth 2.0 plus OpenID Connect – the de facto standard for authentication in SaaS systems. The authorization server issues tokens, the resource server verifies them, responsibility is separated. But a full OAuth implementation does not always make sense. For an internal microservice API, where trust between components is high, a simpler mechanism with API keys and mutual TLS can be sufficient. The decision should follow from the threat model, not from whatever happens to be fashionable.
JWT versus server-side sessions – this is not a “better/worse” choice, but a matter of architectural consequences. JWT gives you stateless verification, the server does not have to query a session store on every request. The price? No immediate revocation. Once issued, a token lives until it expires and there is nothing you can do about it. Server-side sessions allow instant invalidation, but require a shared store (Redis, memcached) in multi-instance environments. At Web Systems we match the mechanism to the context – for public APIs we prefer short-lived JWTs with refresh tokens, for admin panels sessions with immediate revocation.
Tip: Rotate JWT signing keys every 90 days and keep the access token lifetime under 15 minutes. A short TTL minimizes the exploitation window if a token leaks, and regular key rotation limits the impact of a private key compromise.
In multi-tenant SaaS you have to think about RBAC (Role-Based Access Control) versus ABAC (Attribute-Based Access Control). RBAC is enough when roles are fixed and few – administrator, editor, recipient. ABAC comes into play when authorization decisions depend on context: the user’s location, the time of day, the device type or the relationship between a resource and an organization. Isolating data between customers requires tenant-aware middleware that filters every query at the data access layer. And in mobile applications? Secure token storage means the iOS Keychain or the Android Keystore – no discussion. And certificate pinning, because otherwise someone with a substituted certificate will intercept all the traffic.
Security architecture – API Gateway, rate limiting and data validation
An API Gateway is like a guard at the gate – every request goes through it. Centralizing security logic in the gateway makes life easier: rate-limiting rules, header transformations, logging – you define them once and they work for all downstream services. Kong, AWS API Gateway, Envoy – they have this ready to configure. There is no point implementing it from scratch in every microservice.
Rate limiting and quota management protect against DDoS, but they also serve a purely business function – they let you limit resource consumption by individual customers in a subscription model. An effective strategy combines several layers: a global limit per IP, a limit per user, a limit per endpoint, a sliding window instead of a fixed one. And here is the catch – limits that are too aggressive frustrate normal users, and limits that are too loose do not protect against abuse. Calibration requires analyzing real production traffic. Without data you are shooting blind.
An approach based on data, industry analysis and quantitative modeling lets organizations roll out innovative solutions that lead to stronger and more sustainable business results – this also applies to API security architecture, where decisions should follow from measurable risk indicators rather than intuition.
Based on Gartner materials on the data-driven approach
Input data validation – the last line of defense against injection and junk data. Schema validation at the gateway level rejects requests that do not match the OpenAPI specification before they reach the business logic. Parameter sanitization protects against SQL injection, XSS and command injection. At Web Systems we stick to separation of concerns: the gateway is responsible for format and limits, the business layer for domain rules, the persistence layer for parameterized queries. Each layer protects against a different class of threat. Defense in depth without duplicating logic.
Encryption, monitoring and incident response
TLS 1.3 – the absolute minimum for client-server communication. Older versions of the protocol have known vulnerabilities and should not be running in production. For communication between microservices inside a cluster we deploy mutual TLS (mTLS), where both sides verify the partner’s certificate. A service mesh such as Istio or Linkerd automates mTLS certificate management. No more manual rotation and distribution.
Encryption of data at rest covers databases, backups and logs containing sensitive data. But do not overdo it – not everything requires encryption at the application level. If the disk is encrypted (LUKS, AWS EBS encryption), public data does not need an extra layer. Encrypt personal data, tokens, API keys and financial information at the field or record level. The computational cost? With today’s processor performance, negligible. And the benefit if the database leaks – well, do the math yourself.
- Detection – the alerting system spots an anomaly (an unusual traffic pattern, a series of 401/403 errors, a sudden spike in requests from a single source)
- Classification – the team assesses the severity of the incident and confirms whether it is an attack or a false alarm
- Isolation – blocking the source of the attack, revoking compromised tokens, temporarily restricting access
- Analysis – reviewing logs to establish the scope of the breach and the attack vector
- Remediation – patching the vulnerability, rotating secrets, shipping the fix
- Post-mortem – documenting the incident, drawing conclusions and updating procedures for the future
Central logging and API monitoring is not an operating cost. It is an investment in business continuity. At Web Systems we equip every production project with an observability stack – collecting latency, error rate and throughput metrics per endpoint. Automatic anomaly detection based on historical traffic patterns makes it possible to spot an attack before visible business consequences appear. Because you know what? A system without monitoring is a system whose problems you learn about from angry users. And by then it is too late for elegant solutions.
Testing API security across the project lifecycle
Shift-left security – moving security testing as early in the development cycle as possible. Ideally into the CI/CD pipeline, not into the week before the planned rollout (because at that point nobody does it properly anyway). Automated scanning on every pull request catches regressions before they reach the main branch. The cost of fixing a vulnerability found during development is many times lower than the cost of the same flaw discovered in production after an incident. I have checked. The difference can be tenfold.
SAST (Static Application Security Testing) analyzes source code without running it – it detects hardcoded secrets, unsafe patterns and known vulnerable libraries. DAST (Dynamic Application Security Testing) attacks a running API from the outside, simulating an attacker’s behavior. Fuzzing generates random or mutated input, looking for crashes and unexpected behavior. Each of these tools covers a different class of bugs. SAST will find a hardcoded API key. DAST will uncover a missing authorization check on an endpoint. A fuzzer will fish out a buffer overflow in a parser. One tool will not settle the matter.
But manual penetration tests – that is another league. An experienced specialist detects logic vulnerabilities that no automated tool will find. A scenario: a sequence of three valid requests in a specific order lets you bypass authorization. No scanner will catch that. Automated scanning gives you repeatability and broad coverage, but it does not match human creativity in chaining seemingly harmless behaviors into an exploit. The optimal strategy? Both approaches together – continuous automated scanning plus periodic manual pentests.
API contracts defined in the OpenAPI/Swagger format serve not only as documentation. They become a tool for enforcing security standards. You can validate whether every endpoint declares an authorization scheme, whether responses contain no sensitive fields, whether parameters have defined types and ranges. With us, the OpenAPI specification is an artifact reviewed on a par with code – changes to the API contract require approval from both the backend team and the person responsible for security. No exceptions.
FAQ – the most common questions about API security
Does API security in a mobile application require different solutions than in classic SaaS?
The fundamentals are the same – authentication, authorization, encryption, monitoring. The differences sit in the client layer. A mobile application runs in an environment you do not control – the user can decompile it, intercept traffic through a proxy or run it on a rooted device. That is why a mobile API needs additional mechanisms: certificate pinning, device attestation, secure token storage in the Keychain/Keystore and obfuscation of sensitive logic. Web SaaS does not face reverse engineering of the client, but in exchange it has to rigorously isolate data in a multi-tenant architecture. Different problems, but equally serious.
How often should an API security audit be carried out on a live product?
A full manual pentest – at least once a year and after every major change to the architecture or the authorization model. Automated DAST scanning should run continuously – on every deployment or at least once a day on the staging environment. We review the rate-limiting configuration and WAF rules quarterly, because traffic patterns evolve as the user base grows. And the industry matters – fintech and healthtech require more intensive monitoring than a lifestyle app. Which makes sense, really.
How much does implementing solid API security cost and is it worth investing from the start of the project?
API security designed from the start of the project typically means 15-25% of additional budget for architecture and implementation. A lot? Wait. Retrofitting security into an existing system costs 3-5 times more, because it requires rebuilding layers, migrating data and running regression tests. On top of that comes the business risk – a single serious incident generates legal costs, customer churn and reputational damage that far exceed the investment in prevention. From the Web Systems perspective the answer is simple: security from the first sprint is the cheapest option across the entire product lifecycle.
API security is a process, not a one-off task
Three principles that should accompany every architectural decision about an API. Defense in depth – many layers of protection, none of them the only one. Least privilege – every component has the minimum necessary permissions. Fail securely – a failure of a security mechanism does not open access, it blocks it. Do they sound like platitudes? Probably. Until you put them next to production code. Then it turns out the service has admin access to the database, because “it was faster that way”. Or that a catch-all exception handler returns a stack trace with configuration data. I have seen this more than once.
API security is not a checklist to tick off before a rollout. It is part of the development team’s culture. Code review with a security perspective, automated tests in the pipeline, regular training, a shared sense of responsibility. At Web Systems every developer understands why validating tenant_id is critical and why we do not hardcode secrets. Not because someone wrote a rule. Because they have seen the consequences of its absence in the projects we took over for maintenance.
Are you planning to build a new SaaS system, a mobile application with an extensive API, or are you modernizing an existing platform and want to be sure that security is built into the architecture from the foundations? Let’s talk. The Web Systems team will help you audit your current API, design a secure architecture for a new project or strengthen the protection of a live product. Write to us – we will discuss your case with no obligations and point out the specific steps worth taking first.
