Apex Code Development You need to sign in to do that
Don't have an account?
John Brumbelow BUG ParameterizedQuery "q" has flawed documentation and is security risk.
The documentation for using the REST-api's "ParameterizedSearch" has a BUG due to its flawed documentation and this flaw
withotu proper documentation can lead to a security risk.
Source of documentation:
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_search_parameterized.htm
Quote in documentation on the "q":
- "A search string that is properly URL-encoded."
- "SOSL clauses aren’t supported."
- "Available in version 36.0 and later."
BUG: Documentation does not explain this field correctly at all, and worse, the documentation goes on to using "q": "Acme", which if used, will cause all responses to be empty, unless your object happens to have "Acme" literally set in one or more of the fields of one or more of the records found.
To reproduce, follow the sample as-is in the documentation, including the "q": "Acme" sample, but ensure your object does not have any field of any record with "Acme" in it. The response will always be emtpy ==> [].
This is a security risk on top of the flawed documentation, as the "q" causes extra filtering, against ALL fields, and returns only those records with one or more fields that "contain" the "q" value similar to a LIKE statement similar to [ field like '%' + q + '%' ]. Because there is no documentation on "q" to explain this, and that "q" changes the returned data, across all fields similar to a LIKE '%q%', it is a security risk, if the "fields" is set to something that could trigger extra filtering.
Example of security risk:
if "fields" set to "Name" and "q" set to "Acme" from the below records, only 1st 3 would be returned:
Name Email
Acme MyEmail@Acme.com
Acme.Google MyEmail@Google.com
Amazon.Acme MyEmail@Amazon.com
USPS MyEmail@Acme.com
If "fields" is set to "Name", "Email", the return would now return the 4th row.
This is a security risk, as the documentation does not say anything about how "q" should do this.
withotu proper documentation can lead to a security risk.
Source of documentation:
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_search_parameterized.htm
Quote in documentation on the "q":
- "A search string that is properly URL-encoded."
- "SOSL clauses aren’t supported."
- "Available in version 36.0 and later."
BUG: Documentation does not explain this field correctly at all, and worse, the documentation goes on to using "q": "Acme", which if used, will cause all responses to be empty, unless your object happens to have "Acme" literally set in one or more of the fields of one or more of the records found.
To reproduce, follow the sample as-is in the documentation, including the "q": "Acme" sample, but ensure your object does not have any field of any record with "Acme" in it. The response will always be emtpy ==> [].
This is a security risk on top of the flawed documentation, as the "q" causes extra filtering, against ALL fields, and returns only those records with one or more fields that "contain" the "q" value similar to a LIKE statement similar to [ field like '%' + q + '%' ]. Because there is no documentation on "q" to explain this, and that "q" changes the returned data, across all fields similar to a LIKE '%q%', it is a security risk, if the "fields" is set to something that could trigger extra filtering.
Example of security risk:
if "fields" set to "Name" and "q" set to "Acme" from the below records, only 1st 3 would be returned:
Name Email
Acme MyEmail@Acme.com
Acme.Google MyEmail@Google.com
Amazon.Acme MyEmail@Amazon.com
USPS MyEmail@Acme.com
If "fields" is set to "Name", "Email", the return would now return the 4th row.
This is a security risk, as the documentation does not say anything about how "q" should do this.