Comments 9
По поводу правила 11 про пароли в урле — это делается для того, чтобы чувствительная информация не осела в истории браузера, или каких-нибудь логах на промежуточных узлах? Или есть другие причины?
Ещё чтобы её никто не скопировал и не выложил в интернете. Например, задавая вопрос на SO.
Как пример, один из кейсов — если какие-то параметры передаются в урле, то можно легко заставить пользователя пройти по такому урлу, совершив нежелательное действие. Причем, необязательно даже заставлять кликать по ссылке, можно просто вставить этот урл в качестве src атрибута тега img. Мало того, что браузер сделает ненужный пользователю GET запрос, так еще и любезно отправит все пользовательские куки.
А вот заставить браузер сделать запрос на какой-то урл определенными методом, заголовками и телом запроса задача намного более сложная и нетривиальная. Обычной ссылкой тут не обойдешься.
А вот заставить браузер сделать запрос на какой-то урл определенными методом, заголовками и телом запроса задача намного более сложная и нетривиальная. Обычной ссылкой тут не обойдешься.
Если GET делает какое-то действие (не говоря уж о «нежелательное») — то руки отрывать надо за такой REST. И не забываем ограничивать CORS только известными нам доменами (собственными или зарегистрированных сторонних приложений), если есть авторизация пользователя.
Как обычно все зависит от задачи. Есть случаи, когда твоим апи пользуются люди без технических навыков, и они не могут подставить свой ключ в заголовок. Для них и делают параметры в гете, чтобы из браузера можно было дернуть.
Небезопасно — да. Можно сделать форму — да. Но в быстро развивающихся продуктах задачи могут меняться каждый день и безопасность жертвуют в пользу скорости. Тут уже клиент сам отвечает за сохранность своего ключа
Небезопасно — да. Можно сделать форму — да. Но в быстро развивающихся продуктах задачи могут меняться каждый день и безопасность жертвуют в пользу скорости. Тут уже клиент сам отвечает за сохранность своего ключа
Людям без технических навыков нужны не параметры в гете, а официальный клиент...
Какой клиент, вы о чем? Перейти по ссылке и увидеть ответ — вот что хотят пользователи. 11 правило спорное, так как не всегда решает бизнес задачи. Вот взять к примеру shodan — их api поддерживает передачу api ключа в гет параметре
Перейти по ссылке и увидеть ответ
… в формате json? Странные какие-то пользователи.
На практике поставить JSONView в хром проще чем объяснять как сделать POST запрос или добавить заголовок.
Разрабатывать отдельного клиента/страницу для демонстрации работы запросов бывает нецелесообразно
Бывает пока апишка дойдет до технических специалистов ее хотят подергать юристы/бухгалтеры/seo/ceo/уборщицы. Там же можно дать тестовые ключи для демо. Сценариев было много, когда простая ссылка решала много проблем.
Вобщем я просто не согласен с тем, что данные типа ключей надо обязательно выпиливать из параметров. На практике это может быть излишне. Shodan тоже так думает )
Разрабатывать отдельного клиента/страницу для демонстрации работы запросов бывает нецелесообразно
Бывает пока апишка дойдет до технических специалистов ее хотят подергать юристы/бухгалтеры/seo/ceo/уборщицы. Там же можно дать тестовые ключи для демо. Сценариев было много, когда простая ссылка решала много проблем.
Вобщем я просто не согласен с тем, что данные типа ключей надо обязательно выпиливать из параметров. На практике это может быть излишне. Shodan тоже так думает )
Sign up to leave a comment.
Шпаргалки по безопасности: REST