Добрый день. Использование отдельного домена для работы с файлами даёт дополнительную защиту от XSS атаки. Можно рассматривать данную меру в контексте подхода глубинной защиты (defense in depth). Например, файл содержит активный контент (HTML и JavaScript) и браузер воспринимает этот файл как HTML документ (такое возможно, например, в случае отсутствия заголовка X-Content-Type-Options). В таком случае успешная XSS атака тем не менее не даст доступа к основному сайту, благодаря политике одинакового источника (same-origin policy).
Большая часть материала, приведённого в статье, имеет непосредственное применение также и в контексте мобильных приложений (использование HTTPS, авторизация и аутентификация, валидация источника запросов, валидация и санитайзинг пользовательского ввода, предотвращение утечки данных, конфигурация HTTP заголовков и т.д.).
Спецификой мобильного приложения можно считать уязвимость мобильного клиента к обратному инжинирингу, что, например, делает хранение секретных ключей, паролей на клиенте в целом небезопасным (в отличие от веб-приложения). Это в свою очередь создаёт дополнительные трудности при реализации безопасных механизмов аутентификации и авторизации как самого клиента так и пользователей, с необходимостью использовния короткоживущих токенов и аттестации мобильных приложений. Тема сама по себе достойная отдельной статьи.
Добрый день. Использование отдельного домена для работы с файлами даёт дополнительную защиту от XSS атаки. Можно рассматривать данную меру в контексте подхода глубинной защиты (defense in depth). Например, файл содержит активный контент (HTML и JavaScript) и браузер воспринимает этот файл как HTML документ (такое возможно, например, в случае отсутствия заголовка X-Content-Type-Options). В таком случае успешная XSS атака тем не менее не даст доступа к основному сайту, благодаря политике одинакового источника (same-origin policy).
Большая часть материала, приведённого в статье, имеет непосредственное применение также и в контексте мобильных приложений (использование HTTPS, авторизация и аутентификация, валидация источника запросов, валидация и санитайзинг пользовательского ввода, предотвращение утечки данных, конфигурация HTTP заголовков и т.д.).
Спецификой мобильного приложения можно считать уязвимость мобильного клиента к обратному инжинирингу, что, например, делает хранение секретных ключей, паролей на клиенте в целом небезопасным (в отличие от веб-приложения). Это в свою очередь создаёт дополнительные трудности при реализации безопасных механизмов аутентификации и авторизации как самого клиента так и пользователей, с необходимостью использовния короткоживущих токенов и аттестации мобильных приложений. Тема сама по себе достойная отдельной статьи.