Если посмотреть на Graphene, чтобы предоставить публикуемый c API, если бы вы наивно следовали документированным примерам, было бы относительно легко предоставить API, который был бы уязвим для атак типа "отказ в обслуживании", даже если они не не намеренно:
- Не разбитые на запросы запросы могут вернуть слишком много данных.
- Слишком глубокие запросы, возможно, даже циклические запросы, могут привести к слишком большому количеству объединений в вашей базе данных.
По этой причине я склонен сказать, что самый простой подход к защите публичного c API GraphQL - это создание белого списка запросов в работе. Если запрос отсутствует в белом списке, а пользователь не является администратором, отклоните запрос.
Таким образом, возникает вопрос: как сохранить белый список запросов в графене и отклонить запросы, которых нет в этом белом списке? Некоторые идеи:
- Промежуточное программное обеспечение WSGI поверх графена: это проблематично c, потому что это потребует анализа запроса gql, чтобы определить, действительно ли он находится в белом списке. Это работа Графена, так что это не стартер.
- Промежуточное программное обеспечение Графена. Это все еще слишком гранулировано; Промежуточное программное обеспечение Графена, кажется, запускается не один раз на запрос, а скорее на один узел в запросе . Так что это тоже не очень хорошее решение.
Итак, не пытаясь углубиться в исправление обезьян в графене, у меня остается тот же вопрос: как мне реализовать белый список запросов с графеном? (Или, как альтернатива, как мне защитить рабочий сервер Graphene от чрезмерно дорогих запросов?)