Что такое api key
Что такое API простыми словами и для чего он нужен?
Всем привет! Многие наверняка встречали такое понятие, как API, но не все до конца понимают что это такое. Сегодня мы и будем разбираться с этим вопросом. Для начала определимся с самим понятием API.
API – это аббревиатура Application Programming Interface, что означает как интерфейс прикладного программирования. Это можно перевести еще и как программный интерфейс приложений.
Возможно такое определение мало кому о чем говорит. По сути – это набор различных инструментов, функций, благодаря которым одна программа взаимодействует с другой. При помощи API разные программы могут обмениваться своими ресурсами, функциями, информацией. Так, в операционной системе Windows все программы взаимодействуют между собой именно с помощью API.
Таким образом API представляет собой код, который связывает между собой программы. Можно еще определить и как эффективный процесс коммуникаций между программами, которые используют функции и ресурсы друг друга.
Например, посредством API происходит быстрая регистрации в различных приложениях при помощи аккаунта из какой-либо соцсети. Т.е., чтобы предоставить пользователю более простой доступ к своему продукту компания использует специальный код и API.
Что означает API шлюз в программировании?
API-шлюз представляет из себя систему между приложениями для маршрутизации входящих запросов на определенный микросервис. По сути этот шлюз является фильтром трафика. Трафик, проходящий через шлюз (фильтр) обрабатывается с очень высокой скоростью. Причем, модули, входящие в состав шлюза-фильтра можно отключать, если они не нужны или настраивать их как необходимо. Кроме того, API шлюз еще и авторизует пользователя.
Шлюз выполняет следующие функции:
Один из примеров работы шлюзов – смс-рассылки. Для массовой рассылки смс необходим целый комплекс программ, который и называется СМС шлюз. Что бы встроить этот шлюз в какой-либо сайт, который занимается такой рассылкой и потребуется API.
Суть такого смс шлюза заключается для связи абонентов с центром, откуда осуществляются смс-рассылки. Так же, шлюз используется в социальных сетях и мессенджерах.
Таким образом API и API — шлюз это технология, которая позволяет подключаться к некоему ресурсу устройствам с самыми разными операционными системами и прикладным программным обеспечением.
И с этим программным обеспечением он еще и работает, обеспечивая контроль, скорость, безопасность, становясь неким универсальным механизмом. Версии ПО API шлюзов постоянно повышаются под более современные задачи и новое программное обеспечение.
Что значит API сайта и как его использовать?
Вот конкретный пример функционирования API интернет сайта; применяется в следующих случаях:
Когда Вы открываете на смартфоне приложение ВКонтакте по API происходит «узнавание» и дальнейший обмен данными между вашим смартфоном и сайтом. За пару секунд передается масса служебной информации и как результат Вы на экране видите корректное отображение фото, видео в нужном разрешении запускаете игры и т. д. То же относится и к крупным сайтам или интернет магазинам, под которые пишутся приложения ( такие как Авито, Озон, Алиэкспресс и т.д.)
Таким образом, API могут быть публичными, т.е. доступными для всех пользователей, или же приватными, которые используются определенным кругом лиц, например, внутри какой-либо компании или государственной информационной системы
С помощью API можно получать данные от одной программы, которые передаются в другую. Широко применяется API и в веб-разработках. Например, для отображения текста, картинок и прочего в браузере, создается HTML файл, который и содержит в себе эти данные. Подгрузив такой файл в браузер, мы уже видим преобразование из HTML кода (он используется программистом) визуальные элементы, понятные рядовому пользователю – текст, картинки и пр.
Однако, происходит все гораздо сложнее. Текст, который выводит браузер, операционной системой перенаправляется на монитор, который является устройством вывода информации. Во время всех этих операций запускаются функции множества самых различных API.
Одним из самых характерных примеров таких API является Twitter API. Примеры ресурсов, используемых здесь, самые разнообразные. Это не только сам пользователь, но и список твитов, а так же и результаты их поиска. Обращение к каждому из этих ресурсов происходит по его специфическому идентификатору. В основном – это URL адрес.
При запросе приложением какого-либо ресурса с использованием его идентификатора, API отдает запрос от ресурса приложению в том формате, которое наиболее подходит ему. Например, или в JPEG, или HTML-странице.
API браузера уже встроены в них. Они используют данные этого браузера, а так же самой компьютерной среды, чтобы далее совершать более сложные действия. Например, чтобы на карте отметить свое местоположение используется API Геолокации.
При этом в браузере выполняется довольно сложный низкоуровневый код, с помощью которого происходит подключение к устройству геолокации, получаются данные, которые затем передаются браузеру и обрабатываются программой.
Что такое API ключ?
API ключ или API-key – это совокупность номера и проверочного кода, которые создаются специально. Данный ключ является секретным кодом, который служит идентификатором учетной записи пользователя. Вместе с ID пользователя API ключ дает возможность различным сайтам, а так же программам получить доступ к информации о пользователе.
В первую очередь API-ключ предназначен для аутентификации, т.е., подтверждение личности пользователя с использованием идентификатора, имени пользователя и пароля. Возникновение таких ключей было связано с тем, что аутентификация HTTP достаточно уязвима. Этот ключ пользователь может приобрести зарегистрировавшись на специализированном сайте после того, как введет логин и пароль.
API ключи создаются при использовании определенного набора правил, которые устанавливают разработчики API. Каждый раз, когда пользователь или же программа выполняет вызов API, этот ключ необходимо передавать.
Ниже представлено видео, в котором наглядно и доступно рассказывается о том, что такое API ключи.
Теперь вы представляете, что такое API и какое значение сегодня для сайтов и информационных систем они имеют. Охват, универсальность, технологичность. Удачи!
API-ключи
Что такое API?
API — универсальный способ связи разных приложений.
API-ключи позволят другим приложениям получить доступ к вашей учетной записи в eSputnik без необходимости передачи им вашего пароля.
Использование API-ключа
Чтобы настроить интеграцию с вашей организацией в eSputnik, используйте API-ключ.
Ключ дает доступ к данным из вашей учетной записи eSputnik, поэтому он должен быть защищен от несанкционированного доступа.
eSputnik API поддерживает Basic HTTP Access Authentication с использованием API-ключа.
Чтобы авторизоваться и обратиться к ресурсам вашего аккаунта в eSputnik:
Пример авторизации с помощью API ключа для приложения Postman:
Создание и редактирование API-ключа
Чтобы настроить интеграцию со своей учетной записью eSputnik, вам нужно сгенерировать API-ключ.
1. Перейдите в раздел “Настройки”, затем выберите вкладку API и нажмите кнопку “Добавить ключ”. Откроется страница добавления (редактирования) API-ключа.
2. В поле «Описание» можно добавить информацию о том, какое именно приложение/сайт будет использовать этот ключ для доступа к вашему аккаунту в eSputnik. Это поможет в будущем легко идентифицировать данный API-ключ.
3. Вы можете ограничить доступ по API-ключу к рисковым частям вашего аккаунта в eSputnik.
4. Если вам нужно настроить несколько интеграций, вы можете создать ключ для каждой из них. Также для одной организации можно создать несколько ключей с разными правами доступа.
После добавления нового API-ключа в таблице появится строка с соответствующими данными:
Права доступа
Доступ с API-ключом к ресурсам eSputnik устанавливается на этапе создания ключа. Вы можете дать полный доступ ко всем ресурсам и методам eSputnik API, выбрав опцию “Full access to API”, или ограничить его, выбрав:
Следующие правила применимы ко всем версиям методов (/v1, /v2 и т.д.), если иное не уточнено отдельно.
1. Методы API, доступ на которые выдается по умолчанию
Следующие методы не требуют никаких специальных разрешений и доступны в любой из опций.
Общие методы:
Информация об аккаунте:
GET account/info
GET balance
GET subscriptions
GET addressbooks
Управление сообщениями:
POST messages/email
GET messages/email
GET messages/email/
DELETE messages/email/
PUT messages/email/
DELETE messages/email/
PUT messages/email/
GET messages/email/
GET messages/sms
GET messages/sms/
Управление интерфейсами:
GET interfaces/email
GET interfaces/sms
Статистика:
2. Чтение контактов и групп (Read contacts and segments)
Доступные методы API:
GET contacts
GET contact/
GET contacts/email
GET contact/
GET groups
GET group/
3. Обновление контактов и групп (Write contacts and segments)
Доступные методы API:
POST contacts
POST contacts/upload
GET importstatus/
POST contact
PUT contact/
DELETE contact/
PUT contact/
POST contact/subscribe
POST emails/unsubscribed/add
POST emails/unsubscribed/delete
POST group/
4. Управление активностью контактов (Manage contact activity in campaign)
Доступные методы API:
5. Управление ивентами (Manage events)
Доступные методы API:
POST event
POST past_events
DELETE past_events
6. Отправка сообщений (Send messages)
Доступные методы API:
POST message/
GET message/status
POST message/email
POST message/sms
POST message/viber
POST broadcast
GET broadcast/
DELETE broadcast/
GET broadcasts
Блокировка ключа
Если ключ скомпрометирован, вы можете отключить его.
Для этого вам необходимо переместить ползунок напротив ключа в положение “Отключить ключ”. После того, как вы подтвердите свое действие во всплывающем окне, система заблокирует доступ с этим ключом к API.
Порядок действий для разблокировки ключа такой же.
Если ключ не используется в течение 90 дней, он отключается автоматически.
Удаление ключа
Вы можете навсегда удалить ключ, так что его восстановление будет невозможно.
Для этого нажмите на троеточие напротив ключа и в выпадающем списке выберите “Удалить”.
Безопасность API-ключа
API-ключи предоставляют доступ к данным вашей учетной записи eSputnik и должны быть защищены так же, как и ваш пароль. В частности, существует несколько распространенных сценариев, которые следует учитывать при работе с API-ключами.
Что такое api key
Counter-Strike: Global Offensive
Пример:
Форма авторизации открывается в маленьком окне. Поле адреса страницы пустое. Логин и пароль не заполняются автоматически, если сохранены в браузере.
Чуть более продвинутая версия скам формы.Форма авторизации открывается в маленьком окне. Поле адреса поддельное, сделано в виде HTML элемента. Логин и пароль не заполняются автоматически, если сохранены в браузере.
Без действий со стороны пользователя, получить этот ключ невозможно.
Пользователь пополняет какой-нибудь сайт скинами, но деньги на сайт не приходят. Оказалось, он отправил их мошеннику, однако проверочный код трейда совпадал.
Как это происходит?
1) Пользователь нажимает кнопку пополнение счет на сайте
2) Бот сайта присылает пользователю трейд с секретным кодом
4) Мошенник, используя API ключ пользователя, отменяет трейд, который прислал бот настоящего сервиса
5) Мошенник меняет ник своего бота и присылает пользователю трейд с таким же проверочным кодом и с таким же списком вещей.
6) Пользователь принимает трейд, даже не замечая подмены. Процесс скорее всего полностью автоматизирован.
Еще можно попробовать продать что-то дорогое или пополнить счет с помощью SkinPay
Что такое ключ API?
Я вижу это слово почти в каждом приложении перекрестного обслуживания в эти дни.
что такое ключ API и каково его использование?
кроме того, в чем разница между открытыми и закрытыми ключами API.
6 ответов
для чего» точно » используется ключ API, во многом зависит от того, кто его выдает и для каких служб он используется. По большому счету, однако, ключ API-это имя, данное некоторой форме секретного токена, который отправляется вместе с запросами веб-службы (или аналогичными), чтобы определить происхождение запроса. Ключ может быть включен в некоторый дайджест содержимого запроса для дальнейшей проверки происхождения и предотвращения изменения значений.
обычно, если вы можете определить источник запроса положительно, он действует как форма аутентификации, которая может привести к контролю доступа. Например, можно ограничить доступ к определенным действиям API в зависимости от того, кто выполняет запрос. Для компаний, которые зарабатывают деньги от продажи таких услуг, это также способ отслеживания того, кто использует эту вещь для выставления счетов. Кроме того, блокируя ключ, вы можете частично предотвратить злоупотребление в случае слишком больших объемов запросов.
В общем, если у вас открытый и закрытый ключ API, то он предполагает, что ключи сами являются традиционной парой открытого / закрытого ключа, используемой в какой-то форме асимметричная криптография, или связанный, цифровой подписи. Это более безопасные методы для идентификации источника запроса, и кроме того, для защиты содержимого запроса от перехвата (кроме подделки).
ключ API просто идентифицирует вас.
Если есть публичное/частное различие, то открытый ключ-это тот, который вы можете распространять другим, чтобы позволить им получить некоторое подмножество информации о вас из api. Закрытый ключ предназначен только для вашего использования и обеспечивает доступ ко всем вашим данным.
ключ API-это уникальное значение, которое назначается пользователю этой службы, когда он принимается в качестве пользователя службы.
сервис поддерживает все выданные ключи и проверяет их по каждому запросу.
глядя на предоставленный ключ по запросу, служба проверяет, является ли он действительным ключом, чтобы решить, предоставлять ли доступ пользователю или нет.
похоже, что многие люди используют ключи API в качестве решения безопасности. Итог:никогда не рассматривайте ключи API как секретные это не так. На https или нет, кто может прочитать запрос, может увидеть ключ API и может сделать любой вызов, который они хотят. Ключ API должен быть таким же «пользовательским» идентификатором, как и его не полное решение для безопасности даже при использовании с ssl.
Безопасность REST API от А до ПИ
Введение
Умение реализовать грамотное REST API — полезный навык в наше время, т.к. все больше сервисов предоставляют свои возможности с помощью API. Но разработка REST API не ограничивается реализацией HTTP запросов в определенном стиле и формированием ответов в соответствии со спецификацией. Задача обеспечения безопасности REST API не так очевидна, как, например, обеспечение безопасности баз данных, но ее необходимость не менее важна.
В настоящее время многие онлайн системы с помощью API передают приватные данные пользователей, такие как медицинские или финансовые. Текущая же ситуация с безопасностью в веб-приложениях весьма печальна: по данным Comnews порядка 70% содержат критические уязвимости. Поэтому всем, кто участвует в проектировании, реализации и тестировании онлайн систем, важно иметь общую картину по существующим угрозам и способам обеспечения безопасности как всей системы, так и используемого REST API.
В статье я попытался обобщить информацию о существующих уязвимостях REST API, чтобы у читателей сложилась общая картина. На схемах представлена современная архитектура клиент-сервер и обобщенный REST API запрос с потенциальными угрозами безопасности. Далее я подробнее расскажу об этих угрозах, и как технически реализовать защиту от них.
Стандарты безопасности
Начнем со стандартов. Существует несколько стандартов, которые помогут нам сформулировать список требований к безопасности API:
OWASP (Open Web Application Security Project) известна своими списками рисков в разных программных технологиях. Нам интересен список «10 наиболее опасных уязвимостей при разработке API»:
API2:2019 — Broken User Authentication (Недостатки аутентификации пользователей)
Тема аутентификации пользователей идет на втором месте в списке OWASP, но я ее поставил на первое, т.к. с этого все начинается. Современные стандарты аутентификации и авторизации я уже рассматривал в своей статье про OAuth 2.0, OpenID Connect, WebAuthn. Здесь кратко опишу основные схемы безопасности и рассмотрим более подробно наиболее надежную на данный момент схему, основанную на токенах.
API key
API Key — это строка символов, которую передает клиент в запросах к серверу. Для успешной аутентификации строка должна совпадать у клиента и у сервера. Данная схема обеспечивает защиту от несанкционированного использования API и позволяет осуществлять, например, проверку лимитов использования API.
Basic Authentication
В Basic Authentication используется аутентификация по двум строкам, например логину/паролю.
Для передачи информации используется HTTP заголовок ‘Authorization’ с ключевым словом Basic далее пробел и base64 закодированная строка username:password. Например:
Cookie-Based Authentication
Cookie-Based Authentication использует механизм передачи Cookies в HTTP запросах. В ответ на запрос клиента сервер посылает заголовок Set-Cookie, который содержит имя и значение cookie, а также дополнительные атрибуты: expires, domain, path, secure, httponly. Пример отправки cookie:
После этого клиент автоматически будет посылать заголовок Cookie при каждом запросе:
Для реализации этого механизма необходимо на сервере организовать хранение и проверку сессий пользователей. Подробнее использование Cookies рассмотрено в разделе «Insecure Cookies and Local Storage»
Token-Based Authentication
Также называют Bearer Authentication.
Token-Based Authentication использует подписанный сервером токен (bearer token), который клиент передает на сервер в заголовке Authorization HTTP с ключевым словом Bearer или в теле запроса. Например:
При получении токена сервер должен проверять его на валидность — что пользователь существует, время использования не прошло и т.д. Token-Based Authentication может использоваться как часть OAuth 2.0 или OpenID Connect протоколов, так и сервер сам может сформировать токен.
При любом способе аутентификации для безопасного использования должен использоваться протокол, который обеспечивает шифрование данных, HTTP заголовков и URL, например HTTPS.
Алгоритм Token-Based Authentication
Разберем подробнее последнюю из описанных схем. На схеме представлен упрощенный алгоритм Token-Based Authentication на примере реализации возможности «Зайти с помощью Google аккаунта»
В случае перехвата токена, злоумышленник может какое-то время выдавать себя за владельца токена. Поэтому для передачи токена надо обязательно использовать HTTPS.
API1:2019 Broken Object Level Authorization (Недостатки контроля доступа к объектам)
Другое название этого риска: Insecure Direct Object References (Небезопасные прямые ссылки на объекты). Это самая распространенная проблема с API в настоящее время. Для иллюстрации приведу API, которое в дальнейшем использую еще для нескольких примеров уязвимостей.
Получить одного пользователя с userID:
Получить всех пользователей (может только администратор):
Удалить пользователя c userID: DELETE /users/
Итак, если вызывается команда удаления пользователя:
То необходима проверка, что эту команду может вызвать только сам пользователь 1 или администратор, а не, например, пользователь 2 от своего имени, просто изменив значение ID в вызове команды. Чтобы избежать подобных проблем нужно:
API5:2019 Broken Function Level Authorization (Недостатки контроля доступа на функциональном уровне)
Должна быть разработана четкая система разграничения доступа между ролями пользователей API. Например, есть роль: обычные пользователи и роль: администраторы. Команду по просмотру всех пользователей может вызвать только администратор:
При каждом вызове команды необходима проверка прав доступа, чтобы обычный пользователь не мог вызвать команду, только изменив формат.
API3:2019 Excessive Data Exposure (Разглашение конфиденциальных данных)
На самом деле пункт называется — предоставление излишних данных, но при этом как раз и может происходить разглашение конфиденциальных или персональных данных. Как такое получается? На запрос клиента сервер, как правило, формирует запрос к базе данных, которая возвращает запись или список записей. Эти данные зачастую сериализируются в JSON без проверок и отправляется клиенту с предположением, что клиент сам отфильтрует нужные данные. Но проблема в том, что запрос может отправить не только клиент, а может сформировать злоумышленник напрямую к серверу и получить конфиденциальные данные. Например, безобидный запрос данных по пользователю с ID 1:
может вернуть не только имя / возраст, но и ответ на секретный вопрос, который пользователь задал во время регистрации:
Это и называется излишняя передача данных. Проблема усугубляется тем, что лишних данных может быть еще и просто много по объёму. При больших нагрузках это приведет к сетевым проблемам. Соответственно, при разработке API нельзя полагаться на фильтрацию данных в клиенте — все данные должны фильтроваться на сервере.
API6:2019 Mass Assignment (Небезопасная десериализация)
В данном случае ситуация обратная предыдущему пункту Excessive Data Exposure — лишние данные передаются на сервер с целью несанкционированной замены значений. Как это понимать? Предположим у нас есть пользователь-хакер с ID 1 со следующими данными:
Некоторые поля записей пользователь может легитимно менять сам, например, свой возраст. А поля, такие как balance должны устанавливать внешние системы.
Но наш сервер подвержен атаке Mass Assignment и без проверок источника записывает все пришедшие данные. Наш пользователь-хакер может отправить на сервер запрос на изменение возраста, в который добавляет дополнительный атрибут balance:
После этого баланс увеличится без внесения реальных денег. Чтобы предотвратить данную атаку необходимо:
API4:2019 Lack of Resources & Rate Limiting (Отсутствие проверок и ограничений)
Необходимо защитить сервер от атак по подбору пароля (brute force attack). Для этого нужно реализовать следующие ограничения:
Необходимо защитить сервер и от отказа в обслуживании (DoS-атаки)
Если на сервере отсутствует проверка size на максимальное значение, то передача в параметре злоумышленником, например, 1 000 000 может привести к исчерпанию памяти на сервере и отказу в обслуживании. Поэтому нужно проверять на сервере все значения параметров на допустимые, даже если на нашем клиенте есть такие проверки. Ведь никто не помешает вызвать API напрямую.
API7:2019 Security Misconfiguration (Некорректная настройка параметров безопасности)
Следующие действия могут привести к проблемам с безопасностью, соответственно, их надо избегать:
API8:2019 Injection (Внедрение)
Внедрение — это выполнение программного кода, не предусмотренного системой. Разделяют внедрения:
Если сервер выполняет команды без проверки, то злоумышленник может послать следующую команду с большой вероятностью вывода сервера из строя:
Для предотвращения подобных атак:
API9:2019 Improper Assets Management (Недостатки управления API)
API может иметь несколько точек входа (endpoints) с разными версиями и функциональными назначениями. Например:
Необходимо обеспечить учет и контроль версий API:
API10:2019 Insufficient Logging & Monitoring (Недостатки журналирования и мониторинга)
Чтобы выявить атаку или подозрительное поведение пользователей, систему надо мониторить, а события логировать с достаточным уровнем подробности:
Insecure Transport (Небезопасный транспортный уровень)
Если не шифровать трафик между клиентом и сервером, то все HTTP данные и заголовки будут передаваться в открытом виде. Чтобы предотвратить утечку данных, надо использовать протокол HTTPS (Hyper Text Transfer Protocol Secure) или реализовывать шифрование самостоятельно. Для использования HTTPS нужен SSL-сертификат. Сайты в интернете должны получать такие сертификаты в доверительных центрах выдачи сертификатов CA (Certificate Authority). Но для целей шифрования данных между нашим клиентом и сервером можно поступить проще:
Обеспечить поддержку HTTPS можно также средствами Apache, Nginx или других веб-серверов.
Insecure Passwords (Небезопасные пароли)
С этой темой все просто:
Insecure Cookies and Local Storage (Небезопасные Cookies и данные в Local Storage)
Cookies должны использоваться безопасно:
Using Components with Known Vulnerabilities (Использование компонент с известными уязвимостями)
Компоненты, такие как библиотеки и framework-и выполняются с теми же привилегиями, что и приложение. Поэтому если среди используемых библиотек окажется небезопасный компонент, то это может привести к захвату или выводу из строя сервера. Для проверки безопасности компонент используются специальные приложения, например, для JavaScript можно использовать Retire.
CWE-79 Cross-site Scripting (XSS) (Межсайтовое выполнение скриптов)
Межсайтовое выполнение скриптов считается самой опасной web-атакой. Суть ее в том, что вредоносный скрипт может быть внедрен в нашу страницу, а результат выполнения может привести к утечке конфиденциальных данных или к повреждению сервера. Чтобы защититься от атаки в запрос надо включить HTTP заголовок, который включает Cross-site scripting (XSS) фильтр:
CWE-352 Cross-Site Request Forgery (CSRF) (Межсайтовая подмена запросов)
Для понимания сути атаки приведу пример: предположим, есть финансовая организация с онлайн кабинетом. В Cookies запоминается пользователь, чтобы при входе ему не надо было каждый раз вводить свой логин/пароль. Пользователь случайно заходит на сайт злоумышленника, который отправляет в финансовую организацию транзакцию на перевод денег, в которую браузер автоматически помещает данные из запомненных Cookies.
Финансовый сайт успешно проверяет валидность Cookies и выполняет несанкционированную транзакцию. Для защиты от атак CSRF надо:
Cross-origin resource sharing (CORS) (Кросс-доменное использование ресурсов)
CORS — это механизм безопасности, который позволяет серверу задать правила доступа к его API. Например, если на сервере установить заголовок:
то это позволит использовать API без ограничения. Если это не публичное API, то для безопасности надо явно устанавливать Origin-ы, с которых разрешен доступ к API, например:
Также можно ограничивать HTTP методы, которые могут быть использованы для доступа к API:
И задать список заголовков, которые сервер может принимать:
Insecure HTTP Headers (Безопасность HTTP заголовков)
HTTP протокол включает в себя большое число заголовков, которые можно использовать в HTTP запросах/ответах. Для того, чтобы определить наиболее важные заголовки с точки зрения обеспечения безопасности, я использовал несколько списков:
X-Powered-By
Этот заголовок автоматически вставляется некоторыми серверами, что дает понять злоумышленнику, с каким сервером он имеет дело, например:
Отсутствие этого заголовка, конечно, никого не остановит, но сразу давать такую подсказку не стоит. Поэтому передачу этого заголовка надо запретить.
HTTP Strict Transport Security (HSTS)
Strict-Transport-Security заголовок запрещает браузеру обращаться к ресурсам по HTTP протоколу, только HTTPS:
max-age=31536000 — это год в секундах. Рекомендуется выcтавлять этот заголовок, т.к. он предотвратит атаки, связанные с принуждением браузера перейти на HTTP протокол и начать передавать информацию (например cookies) в открытом виде, которую может перехватить злоумышленник. Запрос к серверу по HTTP и атака возможна только при первом обращении к серверу, при последующих браузер запомнит настройку Strict-Transport-Security и будет обращаться только по HTTPS.
X-Frame-Options (защита от Clickjacking)
Позволяет защититься от атаки Clickjacking. Так называется технология, когда злоумышленник помещает кнопку или поле ввода в прозрачный фрейм и пользователь думает, что он нажимает нужную кнопку или безопасно вводит данные, а на самом деле идет перенаправление на другой ресурс, полезный атакующему, например, на сайт с навязчивой рекламой. Для защиты от Clickjacking сервер должен посылать запрет использовать страницу во фрейме вообще:
или разрешить использование только в нашем домене:
А лучше для предотвращения атаки Clickjacking использовать более современный механизм и установить правильную политику безопасности Content-Security-Policy
Content-Security-Policy
Позволяет защититься от атаки Cross-site scripting и других кросс-сайтовых инъекций, в том числе Clickjacking. Требует вдумчивого конфигурирования, т.к. параметров много. Но надо хотя бы поставить дефолтную политику, что предотвратит возможность атаки Cross-site Scripting:
Подробно значения заголовка Content-Security-Policy разбираются, например, по ссылке.
X-Content-Type-Options
Установка данного заголовка запрещает браузеру самому интерпретировать тип присланных файлов и принуждает использовать только тот, что был прислан в заголовке Content-Type. Без этого возможна ситуация, когда, например, посылается безобидный на вид txt файл, внутри которого вредоносный скрипт и браузер его выполняет как скрипт, а не как текстовой файл. Поэтому устанавливаем:
Cache-Control
Cache-Control позволяет управлять кешом на стороне клиента, рекомендуется запретить кеширование, чтобы в кеше случайно не оставались приватные данные:
Заключение
В статье мы рассмотрели угрозы, которые подстерегают API при его эксплуатации и способы борьбы с ними. В заключении приведу несколько общих выводов: