Hello everyone, I'm @xiaoqiangapi, the Chinese teacher who gives apis a "check-up".
An article on [] (HTTP: / / https://dev.to/xiaoqiangapi3721/a-chinese-language-teacher-gave-his-api-a-physical-examination-i-ran-10-securit In y-tests-using-1hpp, I list 10 safety test plans. Today we officially start testing Group 1: ** Authentication *. I'll first address the most fundamental concern of developers - "Can my API be invoked without a Key or with the wrong Key?" *
These are the two things I use: Postman and the curl that comes with Windows. Don't play with virtual.
Test (0) : Normal Request (baseline)

** Result ** : With the correct API Key and valid parameters, 200 OK is returned and the model responds normally.
✅ Basic functionality of the API is normal.
Test (1) : No API Key provided
** Test purpose ** : To see if the API will allow when no API Key is passed.

** Result ** : returns' 401 Unauthorized '.
✅ ** guard against "getting something for nothing" by ** -- not providing the Key, no data at all.
Test (2) : Provide the wrong API Key
** Test purpose ** : Can you get through by deliberately filling in a fabricated Key?

** Result ** : Still '401 Unauthorized', the wrong Key is ruthlessly rejected.
✅ ** by ** -- want to get it for free by guessing keys? No door at all.
Test (3) : The 'messages' array in the request body is empty
Test purpose : Send a correctly formatted but empty request to see if the API wastes resources to process it.

Result : returns 400 Bad Request with an explicit prompt "Please provide a non-empty array of messages".
✅ Passed — API rejects invalid requests, saving computing power and preventing someone from using empty data to cause damage.
Summary of three tests
Three certification tests, ** pass all **.
Test items/Purposes/results /
|---|---|---|
No API Key protected against unauthorized calls: ✅ 401 interception
Incorrect API Key: Prevent guessing Key: ✅ 401 interception
Empty messages prevent invalid requests from wasting resources: ✅ 400 interception
For indie developers or small teams, ** authentication is the first line of defense **. You don't have to worry about being taken advantage of.
Next preview
For the next group, I will test ** injection attacks ** : SQL injection, XSS cross-site scripting, and prompt hijacking. These are the most common tricks of malicious attacks. See what this clumsy method of mine can detect.
If you have other types of attacks you want to test for, or think my testing method can be improved, ** please let me know in the comment section ** - I really need advice from the community because I'm not a security expert.
** 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.
Learn More or Try the API for Free
** Today's interactive question ** : What is your most troublesome authentication issue when invoking the API? Is it the hassle of Key management or the fear of leaks? Let's chat in the comment section.
Top comments (2)
Not a security expert — just Postman and curl. Next up: SQL injection, XSS, and prompt hijacking tests. If you've run similar tests on your own API, what's one thing you'd add that I missed? Curious what other builders worry about.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.