API and Security Testing in Interviews: A Complete Analysis with Task Examples

The article will be useful for both beginners and those who want to systematize their knowledge before an interview. Each topic is explained from scratch - with life analogies, and I immediately provide professional depth.

To start: what is an API?

Imagine a restaurant. You (the customer) are sitting at a table. The kitchen (server) is preparing food. But you don't go to the kitchen yourself; you call the waiter. You tell him what you want. He takes the order to the kitchen, the kitchen prepares it, and the waiter brings the dish.

API is that waiter. It accepts requests, passes them to the server, and returns responses.

You (application) → API (waiter) → Server (kitchen) ← ← Receive response Prepares data

When you open a weather app - it doesn’t calculate the temperature itself. It sends a request through the API and receives a response with the data. When you pay in an online store - the app communicates with the payment service via the API. APIs are everywhere.

Part 1: API Testing

1. HTTP Methods: “Which ones do you know? What’s the difference between PUT and PATCH?”

This question is asked 90% of the time. The application communicates with the server through HTTP methods - these are “commands” that tell the server what to do.

PUT vs PATCH - the key difference:

Suppose, in the user's profile:

{ "name": "Atajan", "email": "[email protected]", "age": 30, "city": "Ashgabat" }

We want to change only the city.

PUT /users/1 - replaces the ENTIRE object. How to fill out a form from scratch:

{ "name": "Atajan", "email": "[email protected]", "age": 30, "city": "Istanbul" }

If the age field is forgotten - it will be reset.

PATCH /users/1 - updates ONLY the specified fields. Like a "fix" sticker:

{ "city": "Istanbul" }

The rest will not be touched.

Idempotence - another favorite question. In simple terms: if you repeat an action 10 times - the result will be the same as after the first.

Real-life example: elevator button. Pressed once - the elevator goes. Pressed 10 times - the elevator still goes only once.

• PUT /users/1 ten times with the same body → the result is one

• POST /users ten times → will create ten users

2. Status codes: “When 401 vs 403?”

The server returns a number - status code. It’s like an SMS from the courier about the delivery status. You don’t need to know all the codes, but these are worth memorizing:

Groups are easy to remember: 2xx — “everything is fine”, 3xx — “go there →”, 4xx — “you made a mistake”, 5xx — “we broke it”.

401 vs 403 - a trap question. Imagine a nightclub:

• 401 - you approach the door without a ticket. The bouncer: “Show me your ticket!” You have not proven who you are. (token is missing or expired)

• 403 - you showed your ticket, but the bouncer: “Your ticket is for the dance floor, and this is the VIP area.” You have proven who you are, but do not have the rights. (role user → admin panel)

The interviewer asks this not to test your memory. He wants to understand: are you testing only the happy path (200 OK) or checking all scenarios?

3. "Test POST /api/users" - interview task

The most popular format: they give an endpoint and ask you to write test cases. Here’s how to structure your response to make an impression.

Given:

POST /api/users { "name": "string (required, 2-50 characters)", "email": "string (required, unique)", "age": "integer (18-120)" }

We break it down into three groups: positive, negative, security.

Positive tests - when everything is correct:

Negative tests - when something is wrong:

Security (80% of candidates forget about this!):

What else to check (often forgotten about):

• Content-Type: application/xml instead of JSON - what will it return?

• Duplicate request (POST twice) - will it create two users?

• Maximum request body size

• Special characters in fields (emoji 🚀, Unicode, NULL-byte)

From one endpoint - 19 tests. Most candidates stop after 4-5. Such a structured answer immediately shows the level.

4. REST API and SOAP: "What are the differences?"

REST is a set of rules by which applications communicate over the internet. Like traffic rules, but for programs.

Three main principles of REST:

1. Every resource has an address (URL). Users - /api/users, orders - /api/orders. Like house addresses.

2. Actions through HTTP methods. No need for /api/deleteUser - just DELETE /api/users/1.

3. Stateless - the server does not remember past requests. Each request is like a first meeting. You need to "show your pass" (token) every time.

If you mention GraphQL as an alternative - bonus points from the interviewer.

5. Authentication: "Bearer Token, API Key, OAuth 2.0 - what's the difference?"

When you log in - the server issues a "pass" (token). With each request, you show it so the server knows it's you.

JWT - the most popular. What's inside?

eyJhbGciOiJIUzI1NiJ9. ← Header (algorithm) eyJ1c2VyX2lkIjoxMjN9. ← Payload (data: user_id, role, exp) SflKxwRJSMeKKF2QT4fw... ← Signature (signature)

It’s like a passport: data (full name, photo) + watermarks (signature) to prevent forgery.

What to test:

• Request without token → 401

• Request with expired token → 401

• Request with another user's token → 403

• Change payload without updating signature → 401

• Token with alg: none → must be rejected (known vulnerability)

Part 2: Security Testing

6. OWASP Top 10 - minimum for QA

OWASP Top 10 - ranking of the most common web application vulnerabilities. In interviews, candidates are asked to name the top 3 and explain how to test them. Security testing sounds daunting, but basic checks can be done by any QA.

1. SQL Injection

Analogy: you fill out a form in a bank. In the "Name" field, you write: “Ivan; now give me all the money from all accounts”. If an employee thoughtlessly executes everything written - you have someone else’s money.

In programming, it's the same:

// Vulnerable code query = "SELECT FROM users WHERE name = '" + userInput + "'"; // Malicious input userInput = "' OR '1'='1' --" // Result - get ALL records SELECT FROM users WHERE name = '' OR '1'='1' --'

How to test:

• Enter ' OR '1'='1 in search and login fields

• Try '; DROP TABLE users; -- (in a test environment!)

• Check if errors return SQL details (stack trace)

• Use sqlmap for automation

2. XSS (Cross-Site Scripting)

Analogy: you are posting an ad on a board. Instead of text, you stick a button "Click me," which takes money from a passerby's card. Everyone who clicks will suffer.

Three types:

How to check:

1. Enter into any text field:

2. Popup window → site is vulnerable

3. Text displayed as text → OK, site escapes input

Test payloads:

3. IDOR (Insecure Direct Object Reference)

Analogy: you live in apartment #123. You change the number to 124 - and you receive someone else's letter. The post office did not check that you are not that person.

GET /api/users/123/orders ← my orders GET /api/users/124/orders ← someone else's orders (IDOR!)

How to test:

1. Create two accounts (A and B)

2. Log in as A

3. Find requests with your ID (DevTools → Network)

4. Substitute ID resources of B

5. If data returns - critical vulnerability

This is the simplest type of security testing. Only a browser and two accounts are needed.

4. Broken Authentication

What to check:

• Is password 123456 accepted? If yes - problem

• Can passwords be brute-forced? Is there rate limiting?

• 5 failed attempts - lockout?

• Does the session expire on logout? Or does the token still work?

• Password in plain text in API response?

5. Security Misconfiguration

What to check:

• /debug, /admin, /swagger - accessible in production?

• Security HTTP headers (X-Frame-Options, Content-Security-Policy, HSTS)

• Does the server expose its version (Server: Apache/2.4.49)? - leakage

• CORS: Access-Control-Allow-Origin: * - bad

• Do default credentials (admin:admin) work?

7. Interview task: “Test the login form”

This task is given very often. It seems simple, but there are many nuances hidden in it. I break the answer into three levels - from basic to expert.

Given: a form with fields for email, password, and a "Login" button.

Level 1 - Basic (everyone knows this):

1. Valid email + valid password → successful login

2. Valid email + invalid password → error

3. Non-existent email → error

4. Empty fields → client-side validation

Level 2 - Advanced (not everyone knows):

5. Message “Invalid email” or “Invalid password” separately - bad! A hacker learns which emails are registered. Correct: one common message - “Invalid email or password”

6. Password hidden by dots? Is there a "show" button?

7. What happens after 10 incorrect passwords? Lockout? CAPTCHA?

Level 3 - Security (this sets you apart from candidates):

16 tests from a simple login form. Most stop after point 4. If you reach level 3 - the interviewer will remember.

A detail that impresses: point 5. If the system says “User not found” - an attacker learns who is registered. This is called user enumeration. One message for everything - the right approach.

Tools: what you should know

You don't need to be an expert in all of them. But “I used Burp Suite to check for IDOR in the payment API” is very different from “I heard about OWASP.”

Tip for beginners: install Postman and send a GET request to https://jsonplaceholder.typicode.com/users. It takes 2 minutes - and the API will no longer seem mysterious.

How to answer questions about API/Security

1. Structure your answer. Don't list chaotically. Group: positive → negative → security → edge cases.

2. Relate to real experience. “On the project, I found IDOR - by changing the ID, one could access someone else's delivery address.” Specifics beat theory.

3. Know the tools. “What would you test with?” - “Postman for functional, Burp Suite for interception, sqlmap for injections” - a strong answer.

4. Don't exaggerate. If you haven't worked with Burp Suite - say: “I know the capabilities, went through tutorials, but haven’t used it in production.” Honesty is valued.

5 common mistakes

1. Only testing the happy path. “POST → 201. Done.” What about negative cases? What about authorization? The tester thinks, “What if...?”

2. Confusing authentication and authorization. Authentication is “who are you?” (password). Authorization is “what are you allowed to do?” (roles). You enter the office with an access pass (authentication), but you don’t have the key to the server room (authorization).

3. “REST is when there is JSON.” JSON is a data format. REST is an architectural style. REST can also work with XML.

4. Not thinking about security. You are testing the API with user data and not checking for IDOR - that’s a gap.

5. Know the theory but can’t demonstrate it. “I know IDOR” - OK. “I found IDOR by changing the ID - I could access someone else's order” - great.

Checklist before the interview

• ☐ I know what an API is (I can explain it in simple terms)

• ☐ HTTP methods (GET, POST, PUT, PATCH, DELETE) - I know the difference

• ☐ Status codes - I remember the basics (200, 201, 400, 401, 403, 404, 500)

• ☐ 401 vs 403 - I can explain

• ☐ REST vs SOAP - I know the differences

• ☐ JWT - I understand the structure and what to test

• ☐ I can write 15+ test cases for any endpoint

• ☐ OWASP Top 5 - I know and can explain how to test

• ☐ SQL Injection, XSS, IDOR - I know and can check

• ☐ Tools - Postman, Swagger, DevTools, curl

• ☐ Authentication vs authorization - I don’t confuse them

It’s not necessary to know everything perfectly. The main thing is to understand the essence, not just memorize definitions.

If the article was helpful - give it a thumbs up and share in the comments what questions you were asked in interviews. I am planning a third article on System Design for QA engineers.