Привет.
Хотите немного безопасности? Тогда читайте данную заметку, а завтра на работе внимательно посмотрите и подумайте, может вам стоит кое-что изменить? Чтобы потом не оправдываться за то, что у вас произошел сбой в системе, вызванный хакерской атакой.
Итак, про безопасность ключей при использовании API
Если ваш API предоставляет первичные ключи вашей базы данных, это создает огромный риск для безопасности.
Например:
$api.com/invoice/131
$ api.com/invoice/132
Если кто-то знает номер своего счета (131), то легко угадать номер счета другого человека (132, 133 и т. д.). Или подобрать его.
Даже если эти счета защищены авторизацией, это все равно рискованно:
- ошибка авторизации раскрывает конфиденциальные данные;
- угадывание идентификаторов также делает его более уязвимым для социальной инженерии.
Есть (как минимум) три возможных решения этой проблемы:
1. Зашифруйте свои первичные ключи, прежде чем открывать их внешнему миру. (кстати, использовать шифрование вообще неплохая идея)
2. Ввести дополнительный столбец «publicID» с UUID - универсальный уникальный идентификатор - про это написано множество статей, если не знакомы с термином то советую ознакомиться или другим безопасным случайным идентификатором (например, hashids.org) (даже такая простенькая процедуры может осложнить третьим лицам получить доступ к данным)
3. Используйте UUID вместо Long в качестве первичных ключей (MySQL и Postgres поддерживают такое решение)
Помните: не допускайте утечки первичных ключей вашей базы данных во внешний мир.
Это может стоит вам карьеры, а компании репутации.