Your Perfect Cybersecurity Partner

Stay Connected:


Techniques to Secure your SOAP and REST API


An API is called as Application Programming Interface, used for communication. An  API acts as a middle man who delivers your request to the provider and then delivers response to the requester. Let’s consider an example: A receptionist in an office gets the query from a guest about accommodation and then informs the manager about it. The manager checks for rooms and intimates the receptionist about the availability. Then the receptionist answers the guest with the availability status.

Web Services use a collection of protocols and standards to exchange data’s between client and server over network. A web service either uses XML (Extensible Mark-up Language) or JSON (Java Script Object Notation) to tag the data. Some commonly used Web services are HTTP, SOAP, WSDL, and UDDI. Under web services, comes a unique category named as API (Application Programming Interface). It has two categories namely SOAP and REST API. Let’s see what SOAP and REST API provides and how to secure them.



  • Some Common API Vulnerabilities
  • Input validation
  • Access Control
  • API without Authentication
  • Keys in URL
  • Replay Attacks
  • Countermeasures
  • Conclusion
  • How Briskinfosec helps you
  • Curious to see our Case study
  • Last but not the least
  • You may be interested on

Some Common API Vulnerabilities:

  • SQL Injection
  • Command Injection
  • XML Injection
  • SOAP Action Spoofing
  • Cross-Site Scripting
  • Cross-Site Request Forgery
  • Broken Access and Authorization related Vulnerabilities.

Common Techniques to Secure SOAP API and REST API:

1. Input validation

A proper input validation is a crucial security measure to avoid injection based attacks such as Cross-Site Scripting, CSRF, SQL injection etc. An input parameter has always been the entry point to penetrate into the layers. For example, a malicious code can be injected in the API message, such as OS command injection which can compromise the entire web application.

Regex Protection: The incoming requests such as URL Path, Header, XML or JSON payload must be evaluated against the regular expressions such as DELETE, UPDATE and EXECUTE. Vulnerable requests must be rejected.

Input HTTP Verb Validation:

HTTP verbs/methods such as GET, POST, HEAD, TRACE, OPTIONS, DELETE, PUT and PATCH should be restricted properly. Only allowed verbs should work and rest of the methods should return a proper response code.

Headers Validations:

Security Headers such as Content-Type, Accept, Content-Length should be validated against API. Also, validation against mandatory headers like Authorization and API-specific headers should be performed.

Validate incoming content-types:

The Content-Type policy for PUT/POST/DELETE requests should be validated such that the incoming request and Content-Type header value should be the same. The API should reject the content with a 404 request when the header is gone missing.

Handle Unsupported Resource:

It must permit only the allowable resources and block the other unknown resources.

2. Access Control:

API gateway should be configured in such a way that allows specific IP domains or regions. Requests which does not meet these conditions should be rejected.

Access types:

When setting up role access, if an access type for a specific operation is not specified, then members of the role do not receive any access privileges for that operation. This has the effect of implicitly disallowing the operation, unless another role grants more permissive privileges.

Never: This function will not let the user to perform any operation, regardless of the role they possess.

Always: In this access level, the user will be able to perform operations, regardless of the role they have.

Grant: Users will be able to perform the operation, unless explicitly disallowed by entity-level permissions.

Entity:Only those users who are granted access through entity-level permissions will be able to perform the operation.

Implement the above access type to all users. By implementing these rules, Broken Access Control can be avoided.

3. API without Authentication:

An API without proper authentication can risk the organization’s databases, showing that the API’s design is an utter failure. Even if TLS was implemented, it can cause problems. If the attacker has the valid mobile number, he can obtain sensitive data such as device details and other personal data. Strong authentication and authorization mechanisms like OAuth/OpenID connect should be implemented. Authenticate both end user and application, if possible.

4. Keys in URL:

As said before, an API should have proper authentication and authorization mechanism. But sometimes, the API key is sent as a part of URI (Uniform Resource identifier) which can lead to the key being compromised, as it appears as plain text in browser. API key sent via GET method can be stored in the browser history or in the system logs as cache, which leads to other user to access it. It is recommended to use HTTP POST method.

5. Replay attacks

API’s that are kept open to public, face the challenge of sorting out whether the incoming requests are legitimate or not. When a web service is exposed over a HTTP request, it can be vulnerable to many attacks. One such among those is the replay attack where an attacker gets hold of the web service request along with the valid input parameters and performs repeated hits, either manually or in an automated fashion. Some impacts of this attack is that it consumes the server’s memory which gradually affects the server’s performance. The attack can inject some malicious codes in the input parameter and might get some confidential data in the response.


1. A Nonce token should be used to avoid the replay attacks. A Nonce token is a combination of unique GUID and a timestamp. The Nonce token works on the principle of one token valid for one request. The GUID (Globally Unique Identifier) is a 128-bit integer number used to identify resources by the developers. With help of GUID value and timestamp, the request will be always unique.

2. Enable 2FA and 0Auth.


In order to develop a secure API, one should properly implement authorization and authentication measures. This is crucial because data must be safe and secure. Last but not the least, one should consider API SECURITY as their nucleus.

How Briskinfosec helps you:

In today’s security landscape, the communication of each and every infrastructure depends solely on API. This is the primary factor for customers and organisations to rely heavily on API. So, any cyberattack on API could be a devastating blow for companies, which may tarnish their reputation horribly. From all these notions, it is evident that the need for securing API isn’t an option but a compulsion. Briskinfosec provides best API security services to all its clients whom want their API services to be secured to the best. Our security folks have a huge experience in doing API assessments and have performed successful API services to many of our clients. Since then, every moment, the bond between them and us has only grown stronger.

If we can secure theirs, why can’t we secure yours?

Get in touch with us and surely it will mean you so much.

Curious to see our Case study:

One of our stakeholder, who is a leading insurance service provider recently asked us to perform a complete API security assessment on all their applications. We did it and sorted out all the vulnerabilities that were lurking secretly. Check out our case study to fully know the way we achieved.

Last but not the least:

Every day, every moment a cyberattack is launched. At least one company’s reputation due to cyberattacks, gets frowned. Searching internet about these attacks, the type of loss experienced, and all these to be searched randomly, in one’s busy life schedule, seems exhausting. But, Briskinfosec understands the pain of people and hence prepares Threatsploit Adversary Report on a monthly basis by gathering various cyberattacks and sculpting all those as a single report, reducing the burden of individuals. This is done because we want people in this earth to be aware of the happenings in cybersecurity.

You may be interested on: