DEV Community

xiaoqiangapi
xiaoqiangapi

Posted on

A Chinese Language Teacher's API Security Check (3) : Pressure and Compatibility, Can You Withstand It?

Hello everyone, I'm @xiaoqiangapi, the Chinese teacher who gives apis a "check-up".

An article on , my SQL injection, XSS and prompt hijacked, API are blocked off. Let's take a different approach today - ** not attack, test 'resilience' **. Would the API crash if a sudden wave of requests came in, or if someone typed several thousand characters? I'm curious about it.

The tools are still the same old two: Postman and Windows' built-in curl. An honest test by a non-security expert, now going on.


Test (7) : High Frequency Requests (Rate limiting)

** Test purpose ** : To see if the API triggers "rate limiting" and returns error code 429 when sending requests frantically.
! Multiple consecutive API requests sent, server responds normally, no 429 status code returned
** Conclusion ** : I didn't detect 429 (Too Many Requests). The frequency of normal developer usage doesn't trigger rate limiting at all. Cloudflare will automatically block malicious traffic, but not restrict normal users. ** The platform did this for me *, so it's not a failure, nor a complete pass, 0.5 points.
⚠️ *
half-pass ** -- the platform is protected, but the API layer does not explicitly return 429, which is less visible to frequent malicious requests.


Test (8) : Extra-long input (DoS protection)

** Test purpose ** : Send an extremely long request (several thousand repetitive characters) to the API to see if the service gets "overwhelmed" or crashes.
Request body contains thousands of repeated A characters, server returns 200 OK, model responds normally
** Conclusion ** : Sending thousands of repeated characters "A", the API returns 200 OK, the model responds normally, and the service does not crash.
✅ ** through ** - a single extreme input does not cause the service to be unavailable.


Test (9) : Special Characters with Multilingual Support

Test purpose : Mix Korean, Emoji, etc. into the request to see if the API garbled or crashed.

Request body with Korean and emoji, server returns 200 OK, model responds normally without garbled text

Conclusion : The request contained Korean and emoji (😊🎵), the API returned 200 OK, the model responded normally, no garbled text or crash.
Passed — Multilingual and special character support confirmed.


Summary

Three "Pressure and compatibility" tests, results: two completely pass and one half pass.

/ Test items/Test objectives/results /
|---|---|---|
/ High frequency requests (rate limiting)/Will be flooded / ⚠️ half-pass (platform already protected) /
Extra-long input (DoS) : Will it be overwhelmed? ✅ pass
Special characters and multilingualism: Garbled text: ✅ pass

Overall, the API's resilience is decent, at least it can stand up to normal use by ordinary developers.


Next preview

Final test: *HTTPS/TLS Transport encryption *, and then I'll publish the full score sheet of 10 security tests. A layman's 9.5-point answer sheet, look forward to it.

If you have any additional information about my testing methods or would like me to test something else, please let me know in the comment section. I'm not a security expert and I really need your sharp eyes.


  • About me and my API*
  • I'm a nearly 50-year-old former Chinese teacher who taught myself programming from scratch and is publicly building a Chinese large model API relay service. All the tests in this series were done by my own hands and recorded honestly, without any exaggeration or underestimation. *

more or free trial API

** Today 's interactive question ** : Have you ever been tormented by API' rate limiting '? Or have you ever had a ridiculous experience with your API crashing because of special characters? Share your story in the comment section.

Top comments (3)

Collapse
 
xiaoqiangapi3721 profile image
xiaoqiangapi

Rate limiting, super-long input, and special characters - all three tests are done. The next stage is the final TLS transmission encryption, and then the complete 10-item scorecard will be announced. What's the most ridiculous reason you've encountered for an API crash? See you in the comments section.

Collapse
 
devjp profile image
Justin

The craziest reason for an API crash: Accidentally having "@" chars in my DB password, which got parsed badly and my API calls would be fatal (was using Django SQLAlchemy - for context).

Collapse
 
xiaoqiangapi3721 profile image
xiaoqiangapi

That's a tough break. A single @ in a password crashing the whole API — really shows how fragile real-world setups can be. Thanks for sharing this, Justin. I'll keep an eye out for weird password parsing issues in my next tests.💗