Друзі, запускаю в пілотному режимі (два тижні) календлі

Якщо вам потрібна порада з #React, або #FrontEnd, або розробкою в цілому - букайте таймслот (понеділок, четвер з 9 по 10 годину)

Також приймаю побажання щодо часу, але не обіцяю що виконаю)). Ну і оскільки це пілот - то буду дуже вдячний за відгуки.

Як проведемо, буду бачити що далі.

Чекліст перед початком нового #FrontEnd проекту

Мінімальний розмір екрану
Визначаємо мінімальний розмір екрану і верстаємо одразу під нього. Перероблювати потім - дорого і довго. Перевіряємося за допомогою Google Developer Tools

"Найгірший" браузер
Дізнаємося який "найгірший" браузер хоче бачити наш замовник і перевіряємо на ньому. Найгірші в моєму порядку черговості - IE (хвала всім його дропнули), Safari, Firefox. Але може бути вимога щоб працювало в Opera Mini або на якійсь екзотиці, тоді готуйтеся страждати.

#SEO
Якщо потрібно SEO - беремо Server Side Rendering (#NextJs/Remix) або взагалі не React. Перероблювати потім суттєво дорожче. Якщо SEO не потрібно - #SSR брати не варто.

Доступність
Якщо треба то який рівень? Норвегія, США, зазвичай це WCAG AA (перекладено українською) для публічно доступних сторінок. Ставимо wave і перевіряємося постійно. Як варіант - в playwright є можливість писати тести для доступності. Дороблювати потім - неймовірно боляче.

Мультимовність.
Якщо так - налаштовуємо одразу і не хардкодимо тексти, а одразу використовуємо компонент що вміє перекладати (FormattedMessage як приклад).

Ще трохи (швидкодія, безпека) є тут

Складно? Так. Рівень джуна? Ні. Але краще про все це думати одразу і домовлятися на березі, аби потім не було дуже боляче. І не забувайте фіксувати ці домовленості письмово - бо усні домовленості люди чомусь "забувають".

Всім добра, допомагайте ЗСУ
@reactbeginners

Продовжуємо серію про налаштування #frontend проекту і тепер потурбуємося про #websecurity.

1. Перевірте, що файл .env.local або його аналог не доданй під git. Так ваші паролі або токени не потраплять в мережу, а ви не отримаєте додаткові рахунки. Всі ключі/токени/паролі які ви використовуються мають зберігатися окремо або в key vault, або хоча б на білд машині яка готує реліз.

2. Налаштуйте перевірку ваших залежностей за допомогою команди npm audit. Ця команда покаже вам пакети, що містять вразливості та допоможе оновити їх щоб це виправити. Для того щоб було менше false positive спрацювань:
- - Перенесіть в dev секцію вашого package.json файлу всі залежності що стосуються розробки - prettier, eslint, jest, і т.д.
- - Використовуйте npm audit з прапорцем --production або --omit=dev.
- - Передайте привіт create-react-app :)

Гарною ідеєю буде інтегрувати цю перевірку в merge фазу пулл реквесту. Або раніше якщо не хочеться все перероблювати :)

3. Безпека runtime. Через особливість налаштування, частіше цим займається команда інфраструктури або бекенду, але частково це можемо налаштувати і ми. Особливо якщо у нас щось накшталт #nextjs

Мова йде про основні безпекові заголовки - Content-Security-Policy (CSP), X-Content-Type-Options, Feature-Policy. А якщо ви ще й піклуєтеся про приватність ваших користувачів то й Referrer-Policy. В разі правильного застосування, за заголовки можуть запобігти або суттєво зменшити шкоду користувачам вашої веб сторінки.

Детальніше про ці заголовки та як їх налаштовувати я розповім в наступному пості, бо лонгріди ж ніхто не читає)

Ваш ЗамПоМиш.

П.М. Ви тут як? Бо останнім часом такий цирк на дроті що голова обертом.

Отже про заголовки #websecurity для #frontend

Заголовків багато, різних, та нас цікавлять наступні:

1. Content-Security-Policy. Уявіть простий сценарій. На вашій сторінці знайшли XSS взраливість (треба про це розповідати?) і вбудували туди свій код. А він бах - і не працює. Чому? Тому що за допомогою CSP ви можете заборонити виконувати вбудований код. Тоді зловмисник може спробувати підвантажити код зі стороннього ресурсу. А це теж не працює, тому що ви обмежили завантаження JavaScript своїм доменом. Так само ви можете задати правила для будь-якого ресурсу - хоч JavaScript, хоч зображення, хоч CSS.

Що цікаво, що для налаштування цього заголовку вам не потрібно турбувати бекенд. Ви можете вказати його за допомогою тегу meta з властивістю http-equiv="Content-Security-Policy"

Правда є з ними і проблеми - складність налаштування (раджу використовувати CSP builder) та конфлікти з Google Analytics домен якої залежить від регіону. Відповідно вам доведеться додавати всі піддомени гугла у white list. Таке собі.

Детальніше почитати можна тут

2. Другий заголовок який нас цікавить - X-Content-Type-Options

Цей заголовок забороняє браузеру тип змісту ресурсів що завантажуються. Це протидії наступній цікавій атаці. Уявіть собі що ви налаштували CSP і заборонили виконувати JS. Зловмисник це побачив і замість файлу з content-type text/javascript відправляє той самий JS але не вказуючи тип. Деякі браузери (не всі), можуть спробувати подивитися в зміст файлу, і спробувати самостійно визначити його тип. Якщо тип буде визначено як JS цей файл буде виконано в обхід CSP.

Заголовок X-Content-Type-Options забороняє браузеру "вгадувати"

Нажаль, для цього заголовку, немає http-equiv, тому віддавати його має саме бекенд

Детальніше можна почитати тут

3. Третій заголовок - Feature Policy або його менш підтрумувана версія - Permission Policy. Тут все просто - цей заголовок вмикає/вимикає певні фічі WebAPI. Наприклад, якщо вашій веб сторінці не потрібна камера, ви можете повідомити браузеру що її вмикати взагалі заборонено. Якщо хтось таки зможе вбудувати XSS у вашу сторінку, камеру увімкнути він все одно не зможе. Так само можна вимкнути геолокацію, оплати, тощо. Це може захистити ваших користувачів раптом щось піде дуже не так.

Налаштовується лише через бекенд, детальніше можна подивитися тут

Заголовків ще є, наприклад X-Frame-Options, Referrer-Policy. Раджу їх також подивитися.

А у мене поки все, дякую всім хто дочитав.