Home  ›  All Blogs  ›  Siddharth-Bezalwar  › 

Beginner’s Guide to RESTful API VAPT – Part 1


Beginner’s Guide to RESTful API VAPT – Part 1

With more and more web applications are developed on top of the web services (RESTful API) many web application penetration tester are wondering exactly how to test these web services and what to actually look for. To help explain how to perform VAPT of REST API, let’s take a quick look at the basics of RESTful API.

What is a RESTful API?

Before understanding RESTful API let’s take a look at what the term REST actually mean.


REST stands for REpresentational State Transfer which is a style of web architecture which describes six constraints.

Uniform Interface

Uniform interface simplifies and decouples the architecture, which enables to each part to develop independently. There are four basic principles for designing uniform interface.

  1. Resource Based – Individual resources are identified in requests using URIs as resource identifiers.
  2. Resource Manipulations Through Representations – A client with a representation of a resource along with its metadata can modify or delete the resource on the server depending on the permissions.
  3. Self-descriptive Messages – Each message contains information to describe how to process the message.
  4. Hypermedia as the Engine of Application State (HATEOAS) – Clients provide state via body contents, query-string parameters, request headers and the requested URI (the resource name). Services provide state to clients via body content, response codes, and response headers.


– No client context should be stored on the server between requests. This means required the state to handle the request is provided within the request as a part of the URI, query-string parameters, request body, or HTTP header.


Responses must implicitly or explicitly specify themselves as cacheable, or not.


Client and server must be separated via a uniform interface.


A client cannot tell whether it is connected directly to the end server, or to an intermediary along the way.

Code on Demand

Servers are able to temporarily customize the functionality of a client by transferring logic to it that it can execute by using JavaScript, JAVA applets, etc.

Complying with these constraints is referred as RESTful. After understanding REST let’s take a look at RESTful Web Services API.

RESTful Web Services (API)

“Representational state transfer (REST) or RESTful web services is a way of providing interoperability between computer systems on the Internet. REST-compliant Web services allow requesting systems to access and manipulate textual representations of Web resources using a uniform and predefined set of stateless operations” – Wikipedia

Web services are implemented using HTTP and the principles of REST. It is a collection of resources with four aspects – base URI of the web service, content type supported by web service, operations supported by web service and API must be hypertext driven.

Aspects of RESTful API

A RESTful API client does not need to know details about the structure of API. It is server’s responsibility to provide necessary information the client needs to interact with the service. The client can interact with APIs with the HTTP methods. Let’s look at different HTTP methods used by the client to interact with APIs.

HTTP Methods for RESTful API

HTTP Method Collection Single Entity
GET Retrieve all resources
Request URL: https://mysite.com/api/users
Retrieve a single specific resource
Request URL: https://mysite.com/api/users/1
HEAD Retrieve all resources (headers only) Retrieve a single specific resource (headers only)
POST Create a new resource in a collection
Request URL:https://mysite.com/api/users
PUT Update/Replace a resource
Request URL: https://mysite.com/api/users/1
PATCH Update/Modify a resource
Request URL: https://mysite.com/api/users/1
DELETE Delete a resource
Request URL:https://mysite.com/api/users/1

HTTP response codes are used to indicate the status of an operation requested by client.

Response Status – HTTP Response Codes

Following are primary or most-commonly-used HTTP response code
200 OK
Indicates the success of requested operation.
Indicates successful creation of entity via either POST or PUT.
Indicates success but nothing is in the response body, generally used for DELETE and PUT operations.
Indicates general error occurred at the server while serving request which resulted in an invalid state. Reasons for such errors are validation error, missing required parameters, etc.
Indicates error code response for missing or invalid authentication token.
Indicates error code for when the user is not authorized to perform the operation or the resource is unavailable for some reason (e.g. time constraints, etc.).
Indicates when the requested resource is not found, whether it doesn’t exist or if there was a 401 or 403 that, for security reasons, the service wants to mask.
Indicates that the requested URL exists, but the requested HTTP method is not applicable.
Indicates a resource conflict occurred. For example, trying to create two users with same information.
Indicates the error which cannot be addressed from the consumer end.
To get a clear picture here is sample request to API end point.

Request to API end point

And it’s response.


Response from API end point

Continue to VAPT part

Get to know more about our process, methodology & team!

Close the overlay

I am looking for
Please click one!