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
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.
- Resource Based – Individual resources are identified in requests using URIs as resource identifiers.
- 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.
- Self-descriptive Messages – Each message contains information to describe how to process the message.
- 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.
Stateless
– 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.
Cacheable
Responses must implicitly or explicitly specify themselves as cacheable, or not.
Client/Server
Client and server must be separated via a uniform interface.
Layered
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.
201 CREATED
Indicates successful creation of entity via either POST or PUT.
204 NO CONTENT
Indicates success but nothing is in the response body, generally used for DELETE and PUT operations.
400 BAD REQUEST
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.
401 UNAUTHORIZED
Indicates error code response for missing or invalid authentication token.
403 FORBIDDEN
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.).
404 NOT FOUND
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.
405 METHOD NOT ALLOWED
Indicates that the requested URL exists, but the requested HTTP method is not applicable.
409 CONFLICT
Indicates a resource conflict occurred. For example, trying to create two users with same information.
500 INTERNAL SERVER ERROR
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
