CODEWITHSUNDEEP
jsonrestxssowaspwebsecurity
java_geek
java_geek

Reputation: 18035

XSS vulnerability for JSON API

I have a REST API that accepts and returns JSON data.

A sample request response is a follows

Request

{
    "repos": [
        "some-repo",
        "test-repo<script>alert(1)</script>"
    ]
}

Response

{
    "error": "Error Message",
    "repos": [
        "test-repo<script>alert(1)</script>"
    ]
}

Is my API vulnerable for XSS?. From what I understand, since the Content-Type is set to application/json, the API as such is safe from XSS. The client needs to ensure that the output is encoded to prevent any XSS attacks. To add an additional layer of security, I can add some input encoding/validation in the API layer.

Please let me know if my assessment is right and any other gotchas that I need to be aware of

Upvotes: 2

Views: 4838

Answers (3)

Simon Bennetts
Simon Bennetts

Reputation: 6186

Your API will not be vulnerable to XSS unless it also provides a UI that consumes it. It will be the clients of your API which could be vulnerable - they will need to make sure they correctly encode any data from your API before they use it in any UI.

Upvotes: 3

fgb
fgb

Reputation: 18569

I think it's right that any XSS issue here is a vulnerability of the client. If the client inserts HTML into a document, then it is its responsibility to apply any neccessary encoding.

The client knows what encoding is required not the server. Different encoding, or no encoding may be needed in different places for the same data. For example:

If a client did something like:

$(div).html("<b>" + repos + "</b>");

then it would be vulnerable to XSS, so repos would need to be HTML encoded here.

But if it did something like:

$(div).append($("<b>").text(repos));

then HTML encoding would have resulted in HTML entity codes being wrongly displayed to the user.

Or if the client wanted to do some processing of the data, it may want the plaintext data first to do the processing, and then encode it later to output it.

Input validation can help too, but the rules for what is valid input may not align with what is safe to use without encoding. Things like ampersands, quotes and brackets can appear in valid text data too. But if your data can't contain these characters, you can reject the input as invalid.

Upvotes: 3

TIAOWANG
TIAOWANG

Reputation: 82

I think your api is vulnerable, though the script may not be execute. Talking to XSS prevention, we always suggest decode/validation dangerous characters when the api deals the input. There is a common requirement "clean the data before it store in the DB".
As for your situation, the api just response a json, but we don't know where the data in json will be used to. usually the frontend accept the data without any decode/validation, if that, there will be a xss.
you talk about that the client use decode the data they get from your api. Yes I agree, but frontend always "trust" the backend so that they won't decode the data. but the api server should not trust any input from frontend due to this can be controlled/changed by (malicious)users.

Upvotes: 0

Related Questions