Кроме этого, также есть интересный отчет и по направлению API Security and Management

#paper #api

Код 401 Unauthorized не про авторизацию

Код и название данной ошибки отражены в названии канала.
Unauthorized вообще можно перевести как "неавторизованый". Однако интересный парадокс в том, что в современном вебе 401 ошибка говорит не об ошибке авторизации, а об ошибке аутентификации.
Такую ошибку чаще всего вернем, если аутентификация запроса была неуспешна. Например, если в запросе отсутствовали необходимые учётные данные (некий токен, sessionID) или проверка их валидности была неуспешной.

При этом для ошибок уже авторизации встречаем как раз код 403 Forbidden. Данный код обычно возвращаем, если с переданными учётными данными к запрашиваемому ресурсу/операции нет доступа. То есть аутентификацию запроса выполнили, но вот доступа уже нет.

Было интересно узнать, если какая-то история под данным "исторически сложилось". Дошел до первого RFC для HTTP/1.0 - RFC 1945 - однако ничего интересного, увы, не нашел. Вероятно, идея была связана с тем же заголовком Authorization, используемым для целей аутентификации.

Конечно, семантика использования "правильных" и "неправильных" кодов ответа при проектировании API - это большой многолетний холивар.
Сюда же можно вспомнить подход, когда порой мы не хотим даже показывать факт существования какого-то ресурса без необходимых прав доступа, и в ответ на запрос будем и вовсе возвращать 404.

#api

Гора родила мышь, а я наконец родил статью на основе материала, про который рассказывал весной на PHDays 2025 и CodeFest 15.

https://habr.com/ru/articles/872918/

#api #oauth #my_publication

Базовые правила правила работы с API в современном мире

Какой громкий заголовок, да ведь? Несколько лет назад я читал в одной компании внутренний доклад "Разрабатываем и тестируем безопасные API", в нем как раз сформулировал тезисно, в виде правил то, что сам интуитивно всегда применял. Мир наш, быть может, и стал более современным, однако свою актуальность правила не потеряли.

Пусть клиент - часть приложения, с которой непосредственно взаимодействуют пользователи и которая распространяется путем доставки определенного ее экземпляра конечным пользователям. Например:
- Браузер (фронтенд в нем)
- Мобильное приложение
- Десктоп-приложение

Тогда можно сказать следующее:
1️⃣ Нельзя доверять тому, что пришло с клиента. Все валидации или проверки должны выполняться на бэкэнде
2️⃣ Нельзя хранить секреты на клиенте. Если секреты хранятся на клиенте, то нельзя их считать секретами
3️⃣ Нельзя выполнять запросы с аутентификацией к внешним API с клиента (следует из п. 2)
4️⃣ Нельзя полагаться на криптографию на клиенте для сокрытия данных от самого пользователя. Шифрование на клиенте имеет смысл только для защиты данных пользователя от бэкенда (здесь изменил исходную формулировку)
5️⃣ Никогда не доверяйте клиентской части «фильтрацию» лишних данных

Как считаете, справедлив ли такой список? Можно ли его чем-то дополнить?


Кстати, откопал и презентацию с того доклада. Подчистил от корпоративной символики и публикую ее здесь.

В ней в том числе есть ссылка на потрясающий материал про CSRF, где рассказывают про Cross-Site Request Forgery в стилистике Гарри Поттера : Defense Against the Dark Arts: CSRF Attacks.
Если никогда не читали, настоятельно рекомендую, подача очень крутая. Даже если и несколько устарел, базовые проблемы не изменились. Есть и перевод на русский.

#api #security

Что нового в мире защиты от CSRF

В продолжение прошлого поста, где упомянул в том числе и CSRF. Мне кажется, мы привыкаем, что для "типовых" задач принципиально новые решения не так и часто появляются. Поэтому особенно интересно обратить внимание на случай, когда позволяемый изменениями в технологиях подход встает сразу на одну ступень с аксакалами мира защиты от CSRF, основанными на токенах.

Еще сначала нужно отметить, что современные CSRF - они не всегда и cross-site, часто по привычке так называют и same-site cross-origin случаи (картинка для тех, кто хочет вспомнить различия между site и origin).

В конце прошлого года наткнулся на статью CSRF Protection without Tokens or Hidden Form Fields. Автор описывает, как в процессе изучения современных подходов к защите от CSRF для имплементации в своем веб-фреймворке он узнал про метод, основанный на Sec-Fetch-Site заголовке. А прочитав статью, узнать об этом можем и мы :)

Идея здесь следующая: все современные (современные, это важно) браузеры умеют отправлять специальный заголовок Sec-Fetch-Site в запросах, причем значение этого заголовка не может быть задано клиентским JavaScript. Заголовок этот может принимать разные значения, а именно:
- same-origin
- same-site
- cross-site
- none

Так мы можем определить отношения между origin, с которого происходит вызов и origin, куда запрос направляется. Главная штука в том, что на клиентской части ничего делать не нужно, браузер заголовок отправит сам, остается только проверять его на сервере. При этом возможно реализовать фоллбэк на какой-либо из классических подходов, если браузер в такие заголовки не сумел.

В декабре был обновлен и CSRF Prevention Cheat Sheet от OWASP, теперь рекомендации есть и там, причем после дискуссий, как понимаю, подняли применимость использования fetch metadata-заголовков до одной из основных мер, а не только как defense in depth. Но при этом подчеркивают, что механизм свежий и раскатывать нужно аккуратно и поглядывая на приборы. Ну и опять же учитывать, если ли у вас пользователи с более старыми версиями браузеров или нет.

На самом деле, мы можем увидеть, что гугл говорил о подобной возможности еще с 2019 года, вот, например, довольна ранняя публикация про fetch metadata. Но товарищ Safari не очень торопился поддержать fetch metadata-заголовки и сделал это только в 2023.


Интересно, если кто-то уже имплементировал работу с таким заголовком, какие еще могут быть нюансы и подводные камни?

#api #security