REST APIs and Next Generation Threats: Part 1

Some days back, when I was going through the record breaking statistics of Facebook and its social networking platform’s REST APIs,  I found phrases likePeople on Facebook install 20 million applications every day. More than 2.5 million websites have integrated with Facebook”. It  really shows the incredible power of REST APIs and probably it is just a start. Apart from Facebook, the list of API providerapplications providing REST APIs is increasing day by day, some of these applications include LinkedIn, Google, Bing, Delicious, GroupOn, Paypal, Twitter, Salesforce and so on. The number of 3rd party applications built on top of REST APIs is also drastically increasing. Probably, we are going to see atleast thousands of 3rd party applications in the near future, built on top of REST APIs, creating a true mesh of applications never seen before.

However, everything comes with a cost and here the cost can be loss of your privacy, social and professional relationships, money and confidential data. As a result, it is extremely important to know and remediate various security risks involved with REST APIs and 3rd party applications. In this post, we will discuss some of the major security risks involved from the perspective of end users. In the end, we will demonstrate a real life scenario of privacy breach of a victim user.

(Read more:  5 easy ways to build your personal brand !)

There are two main scenarios to access API provider application by a user.

Scenario 1:

You access your API provider application directly over the 
HTTP layer with proper security mechanisms provided by the application.

Figure 1: Scenario 1 where a user accesses API provider application directly

Scenario 2 :

You access your API provider application’s features via a 3rd party application on your browser. 3rd party application is responsible for making REST API based calls to API Provider App to implement necessary features. Authentication and authorization is provided by upcoming standard called OAuth.

Figure 2: Scenario 2 where a user accesses API provider functionality via a 3rd party application.

(Read more:  Top 5 Big Data Vulnerability Classes)


Following table shows how a 3rd party application can put a user under various security risks even if API Provider Application is secure from major security flaws. As shown, XSS/CSRF/Broken Authentication puts a user under the same risk as that of 3rd party application. On the other hand, Injection / Broken Authorization puts  you under different risks depending upon exact functionality of 3rd party application.

Scenario 1 Scenario 2
Risk / Security vulnerability API Provider App 3rd Party Application API Provider App
Injection No Yes Scenario Based
Cross -Site Scripting (XSS) No Yes Yes
Broken Authentication No Yes Yes
Cross-Site Request Forgery (CSRF) No Yes Yes
Broken Authorization No Yes Scenario Based

Table 1: OWASP Top 5 Risks and comparison of how an  insecure 3rd party application can make API Provider App insecure.

(Watch more : Checklist: How to choose between different types of Application Security Testing Technologies?)

An illustration

Consider the following scenario where a popular social / professional networking site like LinkedIn or Facebook is an API Provider Application and there are 3rd party applications that provide functionality to make REST APIs calls to them.  Say LinkedIn is secure from CSRF vulnerability, however there is CSRF vulnerability in 3rd Party application and as a result, we will show, it is possible to trick a victim user, say, to add an attacker as a contact in LinkedIn’s professional network.

In summary, attack sequences are described as following. Figure 3 demonstrate the attack sequences diagrammatically.

Figure 3: Flow depicting how an attacker exploits CSRF flaw in a 3rd party application.

Step 1: Attacker creates a blog with title called “REST API for dummies”.  Attacker shares the blog post with the victim user.

The blog recommends 3rd Party application to try REST API calls. 3rd Party application is integrated with LinkedIn using OAuth protocol. OAuth authenticates and authorizes every 3rd party application before it can make any REST API call. Attacker creates a JavaScript exploit embedded in the blog post. The exploit utilizes CSRF vulnerability in the 3rd Party application to send a friend request to the attacker on  behalf of the victim user, without victim user’s real intention and knowledge.




Figure 4: An example blog created by attacker, embedding a JavaScript exploit.

Step 2: Victim user follows the blog and open 3rd Party application in a new tab of web browser.  Victim user selects OAuth option to authenticate and authorize 3rd Party application to make REST A
PI calls to LinkedIn.

Figure 5: 3rd Party application asks for a permission to get access to victim user’s LinkedIn Account

Step 3: The JavaScript exploit, embedded in the blog post, makes a HTTP Post request to 3rd Party on  behalf of the victim user.  As a result of CSRF vulnerability in 3rd Party application, HTTP POST will trigger logic at the backend server of 3rd Party to create a REST API call to LinkedIn. In the current example, exploit will send a fake friend request from victim user to the attacker.  However, as a generic  case, it is possible to post a comment, read the mailbox or perform any other action supported by LinkedIn REST APIs.

Step 4: A friend request email will be sent to attacker. Attacker can easily accept the invitation and add victim user as a friend in LinkedIn’s professional network.

Figure 6: An illustration of successful exploitation. Invitation mail sent to attacker on the behalf of victim user’s LinkedIn Account.


Application Mesh ups and REST APIs bring new dimensions to web application security. Security challenges of REST APIs need to be discussed, formalized and remediated.

In the next few blogs, I will explore some of the following topics:

  1. REST API and Next Generation Threats: Part 2
  2. REST API and Security Remediation from perspective of API providers, 3rd party applications and end users.
  3. REST APIs and role of Web Application Penetration Testing.

Please feel free to provide your valuable comments, questions and suggestions and stay tuned.


More:  Want to be an author? Nominations open for co-authors of CISO Handbook    

Views: 342

Join the Discussion ...

You need to be a member of CISO Platform to join the discussion!

Join CISO Platform



CISO as an enabler

Started by Maheshkumar Vagadiya Jul 30. 0 Replies

Share the instances where you were able to convince the Executive management /board that CISO function is enabler rather then a hindrance.Thanks youMaheshContinue

Has Anyone Evaluated Digital Signature (like Docusign)?

Started by CISO Platform. Last reply by SACHIN BP SHETTY Apr 24. 1 Reply

(question posted on behalf of a CISO member)Has anyone evaluated digital signature (like Docusign), any specific risk/ security areas to be looked into while finalising a vendor? Any and all inputs will be very much appreciated.Continue

What are your strategies for using Zoom in your organization after recent vulnerabilities in news about Zoom platform?

Started by CISO Platform. Last reply by ANAND SHRIMALI May 20. 4 Replies

(question posted on behalf of a CISO member)What are your strategies for using Zoom in your organization after recent vulnerabilities in news about Zoom platform?Related Question: …Continue

[Please Suggest] Corona Virus: Security advisory for work from home

Started by CISO Platform. Last reply by Bhushan Deo Mar 20. 12 Replies

(question posted on behalf of a CISO member)Due to CORONA virus most of the organizations are allowing their employees to work form home.Has any one issued security advisory for work from home ?Continue

Tags: #COVID19

Follow us

Contact Us


Mobile: +91 99002 62585

InfoSec Media Private Limited,First Floor,# 48,Dr DV Gundappa Road, Basavanagudi,Bangalore,Karnataka - 560004

© 2020   Created by CISO Platform.   Powered by

Badges  |  Report an Issue  |  Privacy Policy  |  Terms of Service