API Testing Interview Questions with Answers (Updated 2022)
In this blog post, we want to share some API testing interview questions that could be asked during an API testing interview. The questions are very helpful to make you pass your upcoming interview.
API Testing Interview Questions
1) What do you understand by API testing?
API stands for Application Programming Interface. This is a collection of clearly defined methods of communication between various software components. It can be web-based or desktop-based applications talking to each other using APIs. Web services are one form of API where the application exposes its data and functions as web pages. Examples of APIs are HTML, File Transfer Protocol (FTP), and Simple Object Access Protocol (SOAP).
2) How can you test APIs?
As with any other software testing activity, the objective of API testing is to validate that the tested application works as expected. Since APIs are exposed as a set of clearly defined methods and procedures for communication between software components, they can be tested by following a defined sequence of actions and validating the results for expected behavior. An excellent approach to test APIs is by using tools that record each step performed on the client-side while browsing through each page of your application under test, which automatically generates scripts.
3) What are the different types of API testing?
There are three different types of API testing: Unit testing, Integration testing, and System testing. These can be performed in any order depending on the type of your application under test (AUT). A brief description is as follows:
- a) Unit Testing – APIs are tested using unit tests that focus on trying individual functionalities of the AUT. This is similar to unit testing in the classic test-driven development approach, where unit tests focus on individual components of your application.
- b) Integration Testing – APIs are tested using integration tests where multiple APIs are combined and tested as a single entity. This type of testing is mainly used for web services.
- c) System Testing – APIs can be tested as part of system testing where the complete application is tested using the client and server-side functionalities.
4) What are the different categories of API security testing?
There are four types of API security testing:
- i) Authentication – Ensuring that only authenticated users access the APIs used for critical data and functions. For instance, only the sales team should be able to add and update customer information using APIs.
- ii) Session Management – Identifying session-handling issues such as cookie collision and timeouts could result in authentication failures or unauthorized access to functions and data. For example, if a user starts a session on one browser and then tries to access the same session from another browser, they should be able to log in through both browsers even though they are accessing it from different machines.
iii) Input Validation – APIs are often exposed to user inputs which could be used maliciously if not validated against data type, length, and boundary conditions. For instance: integer values greater than 2147483647 should not be allowed as a parameter to a function that works with string values.
- iv) Output Encoding – Ensuring that an attacker cannot use the output from APIs for malicious purposes such as attacks on the server-side or other clients using the same APIs. For example, URL encoded values included in an email message accessed by the client could be used to perform a cross-site scripting (XSS) attack.
5) What are the common security vulnerabilities you should look for while testing APIs?
Some of the common security vulnerabilities that you should look for while testing APIs include:
- i) Injection – APIs often pass untrusted data (externally supplied) to an interpreter or processor for parsing, transformation, or execution. If this data is not validated before passing it on to the interpreter, injection attacks could lead to information disclosure and system compromise.
- ii) Broken Authentication – Implementation flaws in authentication mechanisms include logging in to a system using valid credentials of another user (e.g., admin), allowing someone to bypass the login process or even existing after logout.
iii) Sensitive Data Exposure – APIs are often used for viewing, adding, and editing information about users, devices, sessions, etc., which should be done using proper authorization. This includes all sensitive data handled by either client or server components of the application under test.
- iv) Denial of Service (DoS) – Testing whether APIs can be used to create or consume excessive resources on the server-side. This could lead to either resource starvation or increased processing time, which could result in DoS attacks.
- v) Security Misconfiguration – These are configuration issues with mobile applications that can make them vulnerable to attacks such as disclosing sensitive information to unauthorized users, performing actions without the user’s knowledge, and denial of service attacks.
- vi) Cross-Site Scripting (XSS) – Security flaw in APIs that allows the injection of client-side scripts into web pages viewed by other users. An attacker can exploit this to steal other users’ session cookies and hijack their sessions.
vii) Insecure Direct Object References – APIs often use direct object references, which allow access to the system’s internal implementation under test, including information about users and other entities on the server-side. An attacker could use this information to gain unauthorized access to files and other resources on the server.
viii) Cross-Site Request Forgery (CSRF or XSRF) – Security flaw in APIs that execute unwanted actions on behalf of an authenticated user without their consent. This is especially prevalent when an API accepts these requests from users with existing sessions.
- ix) If the web application uses cookies to maintain users’ sessions, what are two ways you can attack the web application?
Attacking a web application that uses cookies to maintain user sessions is trivial. Some of the common ways in which you can attack this web application are:
- i) You can set up your website with a similar look and feel to the original website and use social engineering techniques to get users to click on links pointing at your website. This could send additional cookies to your website, which you can use to hijack sessions of legitimate users who have already authenticated on the original website.
- ii) You can use Firesheep or Social-Engineer Toolkit (SET) tools to hijack user sessions over unsecured wireless networks. The devices work by sniffing the network for cookies belonging to users who have authenticated on public wireless networks.
iii) You can also try using publicly available tools such as Tamper Data or Burp suite to tamper with requests sent from your browser to the website and thus get it to set additional cookies for your website session.
6) What kind of testing should you do to show that an application can handle significant database lookups?
When testing whether an application can handle significant database lookups, you could try querying the application using several different inputs. Suppose this results in various types of responses from the web server. In that case, this might indicate that the application is vulnerable to denial of service attacks, which could lead to the crashing of the application.
7) What kind of testing should you do to determine that an API can guard against brute force attacks?
When testing APIs for brute force attacks, you could try using different authentication credentials (i.e., username/password combinations) and see if any combination results in unauthorized access to API functions.
8) What kind of testing should you do to determine that an API can protect against DoS attacks?
When testing APIs for possible denial of service vulnerabilities, you could try sending malformed or abnormally large requests to the application and see if this results in crashing the system. This could also result in a denial of service attack if there is a process that uses these API functions as part of its standard functionality.
9) What kind of testing can you do to show that an application has vulnerabilities related to memory management?
When testing applications for poor memory handling, you could try performing input fuzzing and see if any of the malformed inputs result in a crash or vulnerability. You could also try using Address Sanitizer (ASAN) tools to detect memory management issues.
10) What is the difference between negative testing and positive testing?
Negative testing strives to discover software faults, while positive testing verifies expected functionality. Negative testing can help find vulnerabilities by intentionally breaking or bypassing the software’s security controls. Negative testing is not user-directed and can be effective in black box or grey box testing methodologies.
Positive testing is also known as functional, confirmation, or sanity testing. It strives to validate that a software system complies with its requirements and performs all intended functions while operating within specified boundaries. Positive tests are usually performed by the customer or by operational staff. They use the software as it is designed to be used and report any positive results.
Positive testing cannot find classes of faults such as design faults, implementation faults, and architecture faults. These require a different approach which depends on where the problem lies (e.g., requirements, design, and implementation).
11) What is the difference between static and dynamic testing?
While static testing involves examining web application code without actually running it in an environment that resembles the production one, dynamic testing consists in interacting with a system in its production environment to determine if specific functionality will work as expected.
The above API testing questions are primarily asked during an interview. To ace an interview, one must have a good understanding of the subject. In this article, we discussed various API testing questions and provided answers to them.