Предотвращение повторных запросов на сервере Apollo 2

По соображениям безопасности я ищу способ блокировать неудачных участников от повторных запросов на сервере снова и снова, так как это может привести к плохой производительности исполнения и / или высокой цене развертывания.

В документации сервера Apollo есть ссылка на то, как реализовать наш собственный кеш-сервер с помощью KeyValueCache , но я просто не уверен, как его использовать, чтобы предотвратить повторное выполнение запросов несколько раз.

Возможно, я не рассматриваю весь вопрос под прямым углом, поэтому, пожалуйста, если у вас есть предложения, это будет очень полезно.

Спасибо

Всего 1 ответ


Самое простое решение - реализовать какое-то промежуточное ПО, ограничивающее скорость. Простой пример с использованием экспресс-ограничения скорости

const server = new ApolloServer({ typeDefs, resolvers })
const app = express()

const limitMiddleware = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
})

app.use(limitMiddleware)
server.applyMiddleware({ app })

app.listen({ port: 4000 })

По умолчанию промежуточное программное обеспечение отбрасывает IP-адрес запроса, но если вы хотите получить более подробный и отбросить как IP-адрес, так и имя поля запроса (например), вы можете проанализировать тело запроса с помощью graphql-tag и сгенерировать ключ соответственно ,

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

  1. Ограничение суммы - использование ограничений на уровне хранилища, использование пользовательских скаляров или выполнение проверок внутри решателей для предотвращения возврата слишком большого количества одной «вещи» за раз
  2. graphql-depth-limit запроса - graphql-depth-limit
  3. Ограничение общей сложности запросов и затрат - graphql-validation-complexity и graphql-cost-analysis

Хотя эти инструменты не обязательно затрагивают сценарий в вашем вопросе, я все равно рассмотрю использование какой-либо их комбинации, когда вы погрузитесь в определение того, как защитить свою конечную точку.


Есть идеи?

10000