, скрипт выполнится\n\n// Защита: экранирование HTML-сущностей\nconst safeTerm = escapeHtml(searchTerm);\n```\n\n### 2. Межсайтовая подделка запроса (CSRF)\n**CSRF** заставляет браузер жертвы выполнять нежелательные действия в веб-приложении, где пользователь аутентифицирован. Атакующий создаёт поддельную форму или отправляет запрос от имени пользователя.\n\n**Методы защиты**:\n* Использование **CSRF-токенов**, уникальных для каждой сессии\n* Проверка заголовка `Origin` или `Referer`\n* Требование повторного ввода пароля для критических операций\n\n### 3. Подделка межсайтовых запросов (XSRF/CSRF)\nХотя часто считается синонимом CSRF, некоторые источники выделяют XSRF как отдельный класс атак, связанных с эксплуатацией доверия браузера к cookies.\n\n### 4. Clickjacking (Наведение на фрейм)\nАтакующий накладывает невидимый iframe с целевым сайтом под интерактивными элементами. Пользователь, кликая на кнопку, фактически выполняет действие на целевом сайте.\n\n**Защита**:\n```http\nX-Frame-Options: DENY\nContent-Security-Policy: frame-ancestors 'none'\n```\n\n### 5. Небезопасная обработка данных (Insecure Data Handling)\n* **Утечка данных через кеш браузера**: Критичные данные сохраняются в `localStorage`, `sessionStorage` или кеше\n* **Небезопасная десериализация**: Использование `eval()` или `Function()` для обработки данных\n* **Недостаточная валидация на клиенте**: Проверка только на фронтенде без дублирования на бэкенде\n\n### 6. Атаки на зависимости (Dependency Attacks)\nСовременные приложения используют сотни пакетов NPM, которые могут содержать уязвимости или злонамеренный код.\n\n**Меры предосторожности**:\n* Регулярное обновление зависимостей\n* Использование `npm audit` или `yarn audit`\n* Внедрение инструментов статического анализа (SAST)\n\n### 7. Атаки на конфигурацию CORS\nНеправильная настройка **CORS** позволяет сторонним сайтам получать доступ к данным вашего API.\n\n```javascript\n// Опасная конфигурация\napp.use(cors({\n origin: '*', // Разрешает запросы с любого источника\n credentials: true // Разрешает отправку cookies\n}));\n\n// Более безопасная конфигурация\napp.use(cors({\n origin: ['https://trusted-domain.com'],\n credentials: true,\n methods: ['GET', 'POST']\n}));\n```\n\n### 8. Атаки на веб-хранилище (Web Storage Attacks)\n* **XSS + LocalStorage**: Вредоносный скрипт может читать/записывать данные в хранилище\n* **Утечка через индексацию**: Google может индексировать данные из localStorage\n\n### 9. Атаки на системы аутентификации\n* **Хранение токенов в небезопасных местах**: В `localStorage` вместо `httpOnly` cookies\n* **Отсутствие инвалидации сессии на стороне клиента**\n* **Уязвимости в OAuth/OpenID Connect flow**\n\n### 10. Атаки через сторонние ресурсы (Third-Party Risks)\n* **Скомпрометированные CDN**: Подмена библиотек на вредоносные версии\n* **Уязвимости в аналитических скриптах**: Google Analytics, Hotjar и т.д.\n* **Проблемы с iframe**: Встраивание контента из ненадёжных источников\n\n## Комплексные меры защиты\n\n1. **Внедрение Content Security Policy (CSP)**:\n```http\nContent-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;\n```\n\n2. **Использование современных заголовков безопасности**:\n```http\nX-Content-Type-Options: nosniff\nX-XSS-Protection: 1; mode=block\nReferrer-Policy: strict-origin-when-cross-origin\n```\n\n3. **Регулярное тестирование безопасности**:\n * Автоматизированное сканирование уязвимостей\n * Ручное тестирование (pentesting)\n * Code review с фокусом на безопасность\n\n4. **Защита данных на клиенте**:\n * Использование `HttpOnly` и `Secure` флагов для cookies\n * Очистка sensitive данных из памяти\n * Шифрование критичных данных перед сохранением\n\n5. **Мониторинг и логирование**:\n * Отслеживание подозрительной активности\n * Сбор логов с фронтенда (Sentry, LogRocket)\n * Реагирование на инциденты\n\nФронтенд-разработчики должны осознавать, что **безопасность — это процесс, а не разовое мероприятие**. Недостаточно просто реализовать защитные механизмы — необходимо постоянно обновлять знания, следить за новыми угрозами и проводить регулярный аудит безопасности приложения.","dateCreated":"2026-04-04T21:41:40.843994","upvoteCount":0,"author":{"@type":"Person","name":"deepseek-v3.2"}}}}
PrepBro
← Назад к вопросам

Какие знаешь виды атак на Frontend-приложение?

2.7 Senior🔥 122 комментариев
#Архитектура и паттерны#Браузер и сетевые технологии

Комментарии (2)

🐱
deepseek-v3.2PrepBro AI4 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Основные виды атак на Frontend-приложения

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

1. Межсайтовый скриптинг (XSS)

XSS — одна из наиболее распространённых и опасных атак. Злоумышленник внедряет вредоносный JavaScript-код, который выполняется в браузере жертвы.

  • Reflected XSS: Скрипт внедряется через параметры URL и немедленно выполняется.
  • Stored XSS: Вредоносный код сохраняется на сервере (например, в базе данных) и выполняется при каждом обращении к заражённой странице.
  • DOM-based XSS: Уязвимость существует исключительно в клиентском коде, без участия сервера.
// Пример уязвимого кода для Reflected XSS
const queryParams = new URLSearchParams(window.location.search);
const searchTerm = queryParams.get('q');
document.getElementById('results').innerHTML = `Вы искали: ${searchTerm}`;
// Если q=<script>alert('XSS')</script>, скрипт выполнится

// Защита: экранирование HTML-сущностей
const safeTerm = escapeHtml(searchTerm);

2. Межсайтовая подделка запроса (CSRF)

CSRF заставляет браузер жертвы выполнять нежелательные действия в веб-приложении, где пользователь аутентифицирован. Атакующий создаёт поддельную форму или отправляет запрос от имени пользователя.

Методы защиты:

  • Использование CSRF-токенов, уникальных для каждой сессии
  • Проверка заголовка Origin или Referer
  • Требование повторного ввода пароля для критических операций

3. Подделка межсайтовых запросов (XSRF/CSRF)

Хотя часто считается синонимом CSRF, некоторые источники выделяют XSRF как отдельный класс атак, связанных с эксплуатацией доверия браузера к cookies.

4. Clickjacking (Наведение на фрейм)

Атакующий накладывает невидимый iframe с целевым сайтом под интерактивными элементами. Пользователь, кликая на кнопку, фактически выполняет действие на целевом сайте.

Защита:

X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none'

5. Небезопасная обработка данных (Insecure Data Handling)

  • Утечка данных через кеш браузера: Критичные данные сохраняются в localStorage, sessionStorage или кеше
  • Небезопасная десериализация: Использование eval() или Function() для обработки данных
  • Недостаточная валидация на клиенте: Проверка только на фронтенде без дублирования на бэкенде

6. Атаки на зависимости (Dependency Attacks)

Современные приложения используют сотни пакетов NPM, которые могут содержать уязвимости или злонамеренный код.

Меры предосторожности:

  • Регулярное обновление зависимостей
  • Использование npm audit или yarn audit
  • Внедрение инструментов статического анализа (SAST)

7. Атаки на конфигурацию CORS

Неправильная настройка CORS позволяет сторонним сайтам получать доступ к данным вашего API.

// Опасная конфигурация
app.use(cors({
  origin: '*', // Разрешает запросы с любого источника
  credentials: true // Разрешает отправку cookies
}));

// Более безопасная конфигурация
app.use(cors({
  origin: ['https://trusted-domain.com'],
  credentials: true,
  methods: ['GET', 'POST']
}));

8. Атаки на веб-хранилище (Web Storage Attacks)

  • XSS + LocalStorage: Вредоносный скрипт может читать/записывать данные в хранилище
  • Утечка через индексацию: Google может индексировать данные из localStorage

9. Атаки на системы аутентификации

  • Хранение токенов в небезопасных местах: В localStorage вместо httpOnly cookies
  • Отсутствие инвалидации сессии на стороне клиента
  • Уязвимости в OAuth/OpenID Connect flow

10. Атаки через сторонние ресурсы (Third-Party Risks)

  • Скомпрометированные CDN: Подмена библиотек на вредоносные версии
  • Уязвимости в аналитических скриптах: Google Analytics, Hotjar и т.д.
  • Проблемы с iframe: Встраивание контента из ненадёжных источников

Комплексные меры защиты

  1. Внедрение Content Security Policy (CSP):
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;
  1. Использование современных заголовков безопасности:
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin

  1. Регулярное тестирование безопасности:

    • Автоматизированное сканирование уязвимостей
    • Ручное тестирование (pentesting)
    • Code review с фокусом на безопасность

  2. Защита данных на клиенте:

    • Использование HttpOnly и Secure флагов для cookies
    • Очистка sensitive данных из памяти
    • Шифрование критичных данных перед сохранением

  3. Мониторинг и логирование:

    • Отслеживание подозрительной активности
    • Сбор логов с фронтенда (Sentry, LogRocket)
    • Реагирование на инциденты

Фронтенд-разработчики должны осознавать, что безопасность — это процесс, а не разовое мероприятие. Недостаточно просто реализовать защитные механизмы — необходимо постоянно обновлять знания, следить за новыми угрозами и проводить регулярный аудит безопасности приложения.