На що звертати увагу під час рев'ю коду з погляду безпеки?

Більшість вразливостей потрапляє в код через звичайні PR. Рев'ю - найдешевше місце, щоб їх зупинити, якщо знати, куди дивитися.

1. Авторизація - перше питання до кожного нового ендпойнта:

• чи перевіряється, що користувач має доступ саме до цього об'єкта (політика, authorize, пошук через власника)?
• чи захищені нові методи Livewire-компонентів і дії Filament?
• адміністративні функції - за правами, а не лише «прихована кнопка»?

2. Вхідні дані:

• валідація з межами (довжина рядків, розмір масивів, діапазони чисел);
• $request->validated() у create/update, а не $request->all();
• ідентифікатори власника беруться з автентифікації, а не з тіла запиту.

3. Ін'єкції:

• DB::raw, whereRaw, orderByRaw з даними користувача; назви колонок для сортування - з білого списку;
• {!! !!} у Blade, v-html, dangerouslySetInnerHTML;
• виконання команд (Process, exec), шляхи до файлів з введення користувача.

4. Дані на виході:

• API Resource замість повернення моделі цілком;
• чутливі поля не в журналах, відповідях і повідомленнях про помилки.

5. Секрети й конфігурація:

• ключі в коді, тестах, прикладах конфігурації;
• нові змінні оточення - в .env.example без значень.

6. Зовнішні взаємодії:

• HTTP-запити за URL з введення (SSRF);
• вебхуки - перевірка підпису;
• завантаження файлів - тип, розмір, зберігання поза public.

7. Залежності: нові пакети - чи підтримуються, чи потрібні взагалі, скільки тягнуть за собою.

8. Обробка помилок і стану:

• що відбувається при винятку посеред операції - чи не лишається «напіввідкритого» стану;
• перевірки, що «пропускають» при помилці (fail-open): catch повертає true;
• гонитва: перевірка й зміна балансу без транзакції чи блокування.

Як зробити рев'ю ефективним:

• чекліст у шаблоні PR для змін, що торкаються автентифікації, платежів, файлів, персональних даних;
• автоматика бере рутину (лінтери, SAST, аудит залежностей) - людина зосереджується на логіці й авторизації;
• тести на безпеку - частина PR: «чужий користувач отримує 403» перевіряється тестом, а не на око.

Найчастіший пропуск - не ін'єкції, а відсутня перевірка прав у новому методі, що «просто повертає дані».

Докладніше в документації: OWASP Code Review Guide