BUG: Insecure Input Handling in `getRandomJokes` Endpoint

[parth26nath]

Describe the bug

Bug Report

Description

The getRandomJokes endpoint allows clients to specify fields to include (inc) using a query parameter. However, this implementation lacks proper validation and sanitization of the inc parameter, which can lead to potential security vulnerabilities such as data exposure or injection attacks.

Steps to Reproduce

1. Send a request to the getRandomJokes endpoint with a malicious inc parameter containing unexpected or sensitive fields.
2. Observe if the endpoint returns data including the fields specified in the inc parameter, even if they are not intended for exposure.

Expected Behavior

The getRandomJokes endpoint should validate and sanitize the inc parameter to ensure that only safe and expected fields are included in the response.

Actual Behavior

The getRandomJokes endpoint directly uses the inc parameter without validation or sanitization, potentially exposing unintended data fields to clients.

Impact

• Risk of exposing sensitive or unintended data fields to clients.
• Potential for data manipulation or injection attacks if malicious fields are included in the inc parameter.

Recommendation

1. Implement strict validation and sanitization of the inc parameter in the getRandomJokes endpoint to ensure that only safe and expected fields are included in the response.
2. Use a whitelist approach to validate and filter the fields specified in the inc parameter, rejecting any unexpected or sensitive fields.
3. Consider implementing input validation and sanitization for other query parameters to enhance overall API security.

Code Snippet (Updated getRandomJokes Endpoint)

const incWhitelist = ['field1', 'field2', 'field3']; // Define a whitelist of allowed fields

const updatedJokes = inc
  ? filterObjectKeys(incWhitelist.filter(field => inc.includes(field)), paginatedJokes.data)
  : paginatedJokes.data;


### To Reproduce

_No response_

### Expected behavior

_No response_

### Screenshots

_No response_

### OS

_No response_

### OS Version

_No response_

### Client

_No response_

### Additional context or Information

_No response_

[wajeshubham]

@parth26nath Thank you for pointing out the issue! but I don't think there is any serious security risk here as we are filtering only fields which are present in the data source that we are querying, if any field which is present in the inc does not exist in the object we are just ignoring it. Also, either ways client get all the fields in the response so the fields that we have are not private they are already been accessed by the client so we are okay with exposing the field to our clients.