0

Our system is accepting requests including special characters, see parameter2.

Request [
    {
        "reqHeader": {
            "parameter1": "abc",
            "parameter2": "123456 script>alert(1)</script",
            "parameter3": "2022-11-8"
        }
    }
]

We are not saving data in any database, and we are not returning such data in any of our APIs. But we have been asked to check for validation for special characters. My worry is if we are going to validate each parameter for special characters, it will cause an impact on API performance.

Do I really need to validate such characters in my scenario?

6
  • 1
    "But we are not .... " - you only describe what you do not, but don't describe what you do with these parameters. If you simply discard these - no problem but then why they are needed in the first place. Otherwise - it depends. Nov 8, 2022 at 16:07
  • @SteffenUllrich we just logs them in log file for future reference
    – abc123
    Nov 8, 2022 at 16:08
  • So, you do nothing with the parameter? Then why do you have it?
    – schroeder
    Nov 8, 2022 at 16:09
  • And does anybody who views the log files makes sure that it is only taken as plain text and nothing in it would be interpreted as HTML? As long as you can be sure that the recipient of the data (the one reading the logs) works with the same assumptions as you about the data (i.e. should not be interpreted in any way, including HTML) then this would be fine. Nov 8, 2022 at 16:09
  • 1
    From a security perspective, don't try to blacklist special characters. Instead, have a whitelist of only what's valid; everything else is invalid. Nov 21, 2022 at 6:25

2 Answers 2

1

In general: incoming data should be encoded or escaped according to the expectations of the data sink.

If the data sink is a template which will include the data in raw but will be displayed as HTML - then the expectation is usually that any HTML like things in the data should be properly escaped, unless it is actually expected to be HTML.

If the data sink is an SQL statement then it should be properly escaped to not cause SQL injections (or better: use parameter binding).

If the data sink is just logging which can handle arbitrary data and will not interpret the data in any way, then no escaping or encoding need to be done. But, don't just blindly assume what the expectations are because it seems to be obvious. In the infamous log4j vulnerability it was assumed by most users that a common logging library will just log things without dangerous interpretations. Only this assumption was wrong and could result in remote code execution.

0

User provided data that will be processed in any way, should be scrutinized by default.

Today you may just store the data somewhere and be done with it. Tomorrow, though, a new requirement will be given by a customer/the business that they want to process the data and produce nice HTML reports. Then you will be in trouble because not only will you have to cater for the special characters anyway, you'll also need to find a way to render all the previously stored data safe to use.

If you think that validation will have a significant impact to the API's performance, then you should measure the impact and make an informed decision, rather than base your actions on estimations.

In the end of the day, validation may cause a negligible degradation on your API's performace but unvalidated data may be a show stopper for your future plans.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .