Шото я заколупався)))


Але приніс цікаву ідею: якщо у вас є великі запити до БД, які містять складні join і їх багато з великим обсягом даних, але при цьому дані оновлюються не часто (хай раз на день)
То використайте materialize view, це допоможе зібрати все в одній таблиці і можна зчитати в рази швидше 🔝

Стаття в науковому журналі, яку цитували більше 50 разів в своїх роботах науковці 😆

Всім, хто пише дипломи - присвячується 😂

OWASP Top 10. Або як подарувати мамкіним хакерам доступи 🚬

Уяви: 18:45, п'ятниця. Ти вже закрив ноут подумки.
І тут — повідомлення від тімліда: "є якийсь дивний трафік на проді"
Починаєш дивитись логи. І розумієш — хтось гуляє по системі вже годину. Ось що він використав. І що ти міг зробити раніше.

🔞 A01 — Broken Access Control
Юзер змінив orderId=123 на orderId=124 в URL. І побачив чуже замовлення. Без жодного хаку — просто цифру поміняв. Ти просто забув додати перевірку: а це взагалі його дані?
🔞 A02 — Cryptographic Failures
Паролі в базі — MD5. Без солі. Таблиця на 50к юзерів злита за 20 хвилин через rainbow tables. Ти думав "ну хто буде зламувати саме нас". Виявилось — бот. Йому було все одно, в нього одна задача - знайти паролі. Де він їх шукатиме: проблема розробників, хто не подумав про безпеку даних.
🔞 A03 — Injection
Рядок у формі пошуку: ' OR 1=1 --
Запит повернув всю базу. Один рядок. Без підготовлених statements. Це не міг зробити тільки той, хто знав про вразливість — це міг зробити будь-який школьнік з відповідю claude про sql injection.
🔞 A04 — Insecure Design
Немає rate limit на ендпоінті логіну. 10 000 спроб за хвилину — і пароль підібраний. Це не можна пофіксити хотфіксом. Це треба було думати на етапі дизайну.
🔞 A05 — Security Misconfiguration
S3 бакет з юзерськими документами — публічний. Не навмисно. Просто хтось клікнув не туди при деплої три місяці тому. Ніхто не перевіряв.
🔞 A06 — Vulnerable Components
npm audit показує 4 critical. Вже два місяці. Тікет є. Пріоритет — низький. Одна з вразливостей — саме та, яку зараз експлуатують.
🔞 A07 — Auth Failures
JWT токен підписаний секретом secret. Буквально. Хтось декодував, поміняв role: "user" на role: "admin", підписав тим самим словом — і зайшов як адмін.
🔞 A08 — Integrity Failures
Деплой тягне залежність з GitHub репо третьої сторони. Репо було скомпрометоване тиждень тому. Ніхто не перевіряв хеші. Чужий код вже на твоєму сервері.
🔞 A09 — Logging Failures
Ти дивишся в логи і бачиш... нічого підозрілого. Бо логів майже немає. Хто заходив, що робив, які дані чіпав — невідомо. Ти не знаєш масштаб. І це найстрашніше.
🔞 A10 — SSRF
Фіча "скачати відео по URL" — юзер вводить посилання, сервер робить запит. Хтось ввів http://169.254.169.254/latest/meta-data/ — AWS metadata endpoint. Отримав IAM credentials. Далі — ви отримуєте кости за АВС сервіси, якими навіть не користуєтесь.

Більшість із цього — не складні атаки. Це прості помилки, які роками живуть у коді бо "і так працює". Security не починається з пентесту. Вона починається з наступного релізу.

Чому твій код працює, але його ніхто не може читати 🚬

Включаючи мене. Була п’ятниця. Фіча горить. Я написав — працює, задеплоїв, закрив ноут.
Минуло 3 місяці. Прийшов баг. Починаю читати код і бачу змінні x, i, temp, функцію на 200 рядків і магічне число без пояснення.
Мій код, але що він робить — незрозуміло нікому.

4 простих правила, роби по кіс і не страждай

👾 Неймінг. Назва змінної — це коментар який не застаріє. Якщо треба думати більше секунди що в ній зберігається — назва погана.
👾Розмір функції. Якщо функція називається processData і має 150 рядків — вона робить не одну річ. Вона робить все. Одна функція — одна відповідальність.
👾Магічні числа. Число без контексту — пастка. Для наступного розробника. Часто для тебе самого.
👾Коментарі. “Що” видно з коду. Коментуй “чому” — чому саме таке рішення, чому такий порядок. Навіть якщо код має закручену логіку, коментарі дають контекст. Не потрібно шукати звідки приходить зміна, якщо описані коментарі.

Пиши так, щоб навіть першокурсник зрозумів. Код частіше читають, аніж пишуть. Якщо ти не можеш зрозуміти свій код місячної давнини - це погано.

Кількість вакансій на розробку менша ніж на qa спеціалістів 😉

На доу статистика канешно… навайбокодились 🤣
Але якщо так оцінити, то ринок справді перенасичений розробниками, з 21 року набігло в іт багато людей, а з вайбокодінгом ще більше. От і виходить: швидкість розробки висока, делівері пекельне, а тестувати і контролювати нема кому. Там ще й менеджерських посад ДОФІГА.

Але, такий шторм не довго буде. Вже почалась ші видлига в бігтеху, скоро почнуть зʼявлятися місця, бо швидкість висока, а ціна на Ші інструменти росте і доведеться користуватися економно 💸

Тому вчіться, готуйтеся, скоро буде бум 💥