Pull to refresh
2
0
Send message

Понимаю, что ты хотел увидеть более глубокое разъяснение, а не просто перевод жаргонов. Я старался сохранить важную информацию в первозданном виде, но перевел, чтобы было хоть что-то на русском (некоторые слова на русский дословно не переводятся), да и самостоятельный перевод никто не отменял.

Делать а-ля научный текст, добавляя больше воды, я не хотел.

Но это же не значит, что системы теперь не надо зищищать.

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

В том случае, когда страница входа/регистрации является отдельным приложением, есть ли в нём есть упоминание об адресе основного приложения? Так как, зная адрес основного приложения, можно обратиться к нему и всё равно получить бандлы, из которым можно достать информацию. Т.е. обход такой защиты сводится к определению адреса основного приложения.

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

А если у вас еще и открытое АПИ то вообще в этом все смысла нет... нужно бэк защищать и понимать что все про вас все знают. Ангуляр это или нет, вообще не имеет значение. Есть апишка - ее найдут.

Если вы можете получить доступ в приложение, то, конечно, вы сможете увидеть API запросы и интерфейс приложения. А если зарегистрироваться может не любой? Однако даже в этом случае может быть функционал, который необходимо скрыть от обычных пользователей, например, страница администратора с её интерфейсом и API запросами.

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

Information

Rating
Does not participate
Registered
Activity

Specialization

AppSec-Engineer