TypeError: Argument 1 passed to Solarium\QueryType\Select\Query\Query::addSort() must be of the type string

Problem/Motivation

When attempting to sort the search on a non existing field server returns HTTP code 500 (WSOD).

Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend::setSorts() will pass user submitted string directly to Solarium\QueryType\Select\Query\Query::addSort() without checking if that string is valid sort or not.

This will cause warning and TypeError because Drupal\search_api_solr\Utility\Utility::getSortableSolrField won't be able to find sortable field and will return NULL.

Warning: reset() expects parameter 1 to be array, null given in Drupal\search_api_solr\Utility\Utility::getSortableSolrField() (line 531 of web/modules/contrib/search_api_solr/src/Utility/Utility.php).

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Solarium\QueryType\Select\Query\Query::addSort() must be of the type string, null given, called in web/modules/contrib/search_api_solr/src/Plugin/search_api/backend/SearchApiSolrBackend.php on line 4143 in Solarium\QueryType\Select\Query\Query->addSort() (line 415 of vendor/solarium/solarium/src/QueryType/Select/Query/Query.php).

Stack trace:
Solarium\QueryType\Select\Query\Query->addSort(NULL, 'desc') (Line: 4143)
Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend->setSorts(Object, Object) (Line: 1453)
Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend->search(Object) (Line: 468)
Drupal\search_api\Entity\Server->search(Object) (Line: 539)
Drupal\search_api\Query\Query->execute() (Line: 575)
Drupal\search_api\Plugin\views\query\SearchApiQuery->execute(Object) (Line: 1426)
Drupal\views\ViewExecutable->execute(NULL) (Line: 52)
Drupal\webprofiler\Views\TraceableViewExecutable->render() (Line: 183)
Drupal\views\Plugin\views\display\Page->execute() (Line: 1630)
...

Note: all the line numbers above correspond to release 4.1.4.

Valid reason when invalid sort string may be submitted is after sortable field has been removed from the index but search engines not aware of this change continue attempting to access URLs containing the outdated sort.

I also encountered cases when malicious users attempt to exploit the site by providing encoded SQL queries as sort.

Steps to reproduce

Supply non-existing field name as sort parameter.

For example assume there is a search view at the path: /search.

Visit the URL /search?sort=nonexisting_field&order=desc

Order parameter is irrelevant here. It can be either 'desc' or 'asc'.

Proposed resolution

Attempt to add sort only if the string passed as sort matches known/existing field. Ignore all other strings.

When visiting URL /search?sort=nonexisting_field&order=desc I expect invalid sort to be ignored and search results returned as if sort wasn't defined at all.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.