Performance testing and security testing are different jobs, but a load test is the cheapest way to check one specific security question: do your protective controls still work when the system is busy? Rate limits, login throttling, request size caps and resource quotas are security controls, and they only prove themselves under volume. That is the argument of this post, and it is narrower than “fold penetration testing into load testing”, which I do not recommend. An earlier version of this page made that wider claim with unsourced figures and invented scenarios; those are gone.
Key Takeaways
- A load test cannot replace a penetration test or a code review. It can verify that limits and throttles enforce what you configured, and that errors under pressure do not leak or fail open.
- OWASP lists Unrestricted Resource Consumption as API4:2023 in its API Security Top 10. Its prevention list reads like a load-test checklist.
- Test only systems you own or are authorised to test. A load test against someone else’s service is an attack, whatever you call it.
- Keep the scope honest: a load test run from rented generators does not reproduce a volumetric DDoS, and it should not try to.
Why does security belong in a load test?
Because several security controls are really capacity controls. OWASP’s API Security Top 10 (2023 edition) puts it plainly under API4:2023, Unrestricted Resource Consumption: API requests consume bandwidth, CPU, memory and storage, and some calls are paid per use at a third-party provider. Exploiting a missing limit “can lead to DoS due to resource starvation” and can also raise operational costs (api-security.owasp.org, read 23 October 2026). Its example scenarios include a password-reset endpoint that triggers tens of thousands of paid SMS messages, a GraphQL request that batches many image uploads past per-request checks until the server runs out of memory, and a cached file that outgrows its limit and takes a cloud bill from about $13 to $8,000 a month.
None of those is found by a functional test or a scanner that sends one request at a time. They show up when you send many requests, which is what a load test does. OWASP’s prevention list is the testable part: cap memory and CPU per container, set maximum sizes for payloads and array lengths, apply rate limiting with stricter limits on sensitive endpoints, restrict how often one client can validate a one-time code or ask for password recovery, bound the number of records a response returns, and set spending limits or billing alerts with every paid provider.
Which security controls can a load test verify?
| Control | What to run | What a pass looks like |
|---|---|---|
| Rate limiting on sensitive endpoints (login, password reset, OTP check) | Many requests from one test identity, then from many | Requests beyond the limit are rejected (often with HTTP 429), the limit holds under concurrency, and normal users are not rejected |
| Login throttling or lockout | Concurrent failed logins against one test account you created | The lockout triggers at the configured count and not several attempts later; concurrent requests can race a naive counter, so test it |
| Payload and pagination caps | Oversized bodies, long arrays, a huge page-size parameter | A clean 4xx, memory flat, no unbounded response |
| Per-request cost (batching, expensive queries) | Requests that batch many operations in one call | Server cost scales with a limit, not with whatever the caller packs in |
| Fail-closed behaviour | Push authentication or authorisation dependencies into timeouts | Requests are denied, not allowed through, when a check cannot complete |
| Error responses under stress | Drive the service past capacity | Errors are generic; no stack traces, internal hostnames or tokens in 5xx bodies |
| Spending caps on paid providers | A bounded run that exercises SMS, email or third-party API calls | Billing alerts or caps trip before real money does; use a sandbox account or mock where you can |
The fail-closed and error-body rows are the ones teams skip. A system that returns detailed errors only when it is overloaded will not show that in a quiet test.
What does a load test not cover?
- Vulnerabilities in code. SQL injection, broken access control or insecure deserialisation need security testing, code review and scanners. A load test sending valid-looking traffic will not find them.
- Volumetric attacks. CISA, the FBI and MS-ISAC’s DDoS guidance (updated March 2024) separates volumetric attacks, which consume bandwidth, protocol attacks and application attacks (cisa.gov, read 23 October 2026). A load test from a few rented generators is closest to the application-attack case; it does not reproduce a flood that saturates your network edge. Defence there is the provider’s and your CDN’s job, and your test plan should not try to prove otherwise.
- Real attackers. A test uses the traffic shape you scripted. Attackers choose their own.
Do you only test systems you own?
Yes, and this is the rule that matters most. Only load test systems you own or are explicitly authorised to test, in writing, with the owner of every dependency your traffic touches. That includes third-party APIs, payment sandboxes, SMS and email providers, and shared hosting. Check your cloud and CDN provider’s testing policy before a large run. Never aim a security-flavoured load test at a production system without agreeing the window, the volume ceiling and who can stop it.
Where does this fit in a secure development process?
NIST’s Secure Software Development Framework, SP 800-218 version 1.1 (February 2022), is a set of high-level secure development practices that organisations add to whatever lifecycle they already run, aimed at reducing vulnerabilities in released software and their impact (csrc.nist.gov, read 23 October 2026). A load test that verifies throttling and resource limits is one concrete verification step you can slot into that, next to the checks that are not about load. I only read the abstract, so I am not citing a specific practice number.
At the application level, OWASP’s ASVS has a requirement for anti-automation controls. In ASVS 5.0, as mapped by OWASP Cornucopia (read 23 October 2026), V2.4.1 asks for controls against excessive calls that could cause data exfiltration, quota exhaustion, rate-limit breaches, denial of service or overuse of costly resources, and it applies at Levels 2 and 3. A load test is how you demonstrate that such a control does what it claims.
How do you start?
- List your sensitive and expensive endpoints: login, password reset, one-time-code checks, search, exports, anything that calls a paid provider.
- Write down the limit each should have. If nobody can say what it is, that is the first finding.
- Build one scenario per limit, using test accounts and a non-production environment where you can.
- Run at and past the limit, and record both sides: do attackers get stopped, and do ordinary users keep working (see percentiles versus averages for reading the second half).
- Repeat after changes to throttling, gateways or auth, as a regression check.
For the pieces this post does not repeat: cloud testing security best practices covers protecting test data and credentials; API rate limiting causes covers what the limits look like from the client side; spike testing covers sudden bursts; and endurance testing covers leaks that appear after hours.
LoadFocus runs cloud load tests for websites and APIs, and JMeter and k6 scripts, from 25+ regions (loadfocus.com, 23 October 2026); see the load testing page. Use it only on targets you are authorised to test.
Frequently Asked Questions
What is performance testing security?
Checking that security controls keep working under load: rate limits, throttling, resource caps, fail-closed behaviour and safe error responses. It is a verification of controls, not a replacement for penetration testing.
Should load tests include vulnerability scanning?
Keep them separate. A scanner and a load test have different goals and mixing them makes results hard to read. Run the scan and the load test on their own schedules, and correlate the findings.
Can I use a load test to simulate a DDoS attack?
Only against systems you own or are authorised to test, and only as an application-level exercise. A load test from rented generators does not reproduce a volumetric flood. CISA’s guidance distinguishes volumetric, protocol and application attacks; plan your test against the last.
How often should I run these tests?
After any change to rate limits, gateways, authentication or resource limits, and on a regular schedule so drift shows up. There is no sourced figure for an ideal cadence; choose one based on how often those controls change.
Sources
- OWASP API Security Top 10 2023, API4:2023 Unrestricted Resource Consumption (api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption), read 23 October 2026.
- NIST SP 800-218, Secure Software Development Framework version 1.1, February 2022 (csrc.nist.gov/pubs/sp/800/218/final), abstract read 23 October 2026.
- CISA, FBI, MS-ISAC, Understanding and Responding to Distributed Denial-of-Service Attacks (cisa.gov), 21 March 2024; the landing page was read, the PDF was not.
- OWASP ASVS 5.0 anti-automation, V2.4.1, via OWASP Cornucopia’s ASVS 5.0 taxonomy (cornucopia.owasp.org), read through a search result 23 October 2026.
