Как сделать так, чтобы вложенные нападение на GraphQL/Аполлон сервер?

На момент написания статьи в GraphQL-JS или Apollo Server нет встроенной функции для решения этой проблемы, но это то, что определенно должно иметь простое решение, поскольку GraphQL становится все более популярным. Эта проблема может быть решена с помощью нескольких подходов на нескольких уровнях стека, а также всегда должна сочетаться с ограничением скорости, чтобы люди не могли отправлять слишком много запросов на ваш сервер (это потенциальная проблема с REST).

Я просто перечислю все различные методы, которые я могу придумать, и я постараюсь держать этот ответ в актуальном состоянии, поскольку эти решения реализованы на различных серверах GraphQL. Некоторые из них довольно просты, а некоторые более сложны.

1. проверка запроса: на каждом сервере GraphQL первым шагом к запуску запроса является проверка - это когда сервер пытается определить, есть ли какие-либо серьезные ошибки в запросе, чтобы мы могли избежать использования фактических ресурсов сервера, если мы сможем найти, что это так. существует некоторая синтаксическая ошибка или недопустимый аргумент спереди. GraphQL-JS поставляется с набором правил по умолчанию, которые следуют формату, очень похожему на ESLint. Так же, как существует правило обнаружения бесконечных циклов во фрагментах, можно написать правило проверки для обнаружения запросов с слишком большой вложенностью и отклонить их на этапе проверки.
2. Время ожидания запроса : Если невозможно определить, что запрос будет слишком ресурсоемким статически (возможно, даже мелкие запросы могут быть очень дорогими!), то мы можем просто добавить тайм-аут для выполнения запроса. Это имеет несколько преимуществ: (1) это жесткий лимит, о котором не слишком трудно рассуждать, и (2) это также поможет в ситуациях, когда один из бэкендов занимает неоправданно много времени, чтобы ответить. Во многих случаях пользователь вашего приложения предпочтет отсутствующее поле ожиданию ответа более 10 секунд.
3. Query whitelisting : это, вероятно, самый сложный метод, но вы можете заранее составьте список разрешенных запросов и сверьте все входящие запросы с этим списком. Если ваши запросы полностью статичны (вы не выполняете динамическую генерацию запросов на клиенте с помощью чего-то вроде ретранслятора), это самый надежный подход. Вы можете использовать автоматизированный инструмент для извлечения строк запросов из ваших приложений, когда они развернуты, так что в процессе разработки вы пишете любые запросы, которые хотите, но в рабочей среде пропускаются только те, которые вы хотите. Еще одно преимущество такого подхода это означает, что вы можете полностью пропустить проверку запросов, так как вы знаете, что все возможные запросы уже действительны. Для получения дополнительных преимуществ статических запросов и белого списка, прочитайте это сообщение: https://dev-blog.apollodata.com/5-benefits-of-static-graphql-queries-b7fa90b0b69a
4. ограничение стоимости запроса : (добавлено в правке) подобно тайм-аутам запроса, вы можете назначить стоимость различным операциям во время выполнения запроса, например запросу базы данных, и ограничить общую стоимость клиента. может использоваться для каждого запроса. Это можно совместить с ограничением максимального параллелизма одного запроса, чтобы предотвратить отправку клиентом чего-то, что инициирует тысячи параллельных запросов к вашему бэкенду.

(1) и (2) в частности, вероятно, то, что каждый сервер GraphQL должен иметь по умолчанию, тем более что многие новые разработчики могут не знать об этих проблемах. (3) будет работать только для определенных видов приложений, но может быть хорошим выбором, когда есть очень строгие требования к производительности или безопасности.