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

OWASP Top 10 — индустриальный стандарт классификации самых критичных уязвимостей веб-приложений, обновляемый раз в 3-4 года. Это не исчерпывающий список (есть OWASP Top 10 API, OWASP ASVS), но это первый чек-лист, который должен проходить любой production-проект. Знание Top 10 — маст-хэв для middle и senior.

Хранение паролей — первый и самый частый источник катастрофических утечек. Все известные мега-утечки последних 10 лет (LinkedIn, Adobe, Yahoo) случились с базами, где пароли хранились в plain text или с устаревшим хешированием. Современный стандарт — adaptive hashing: bcrypt или argon2id, с медленностью, рассчитанной так, чтобы перебор стоил миллиарды лет.

// config/hashing.php — драйвер и cost
return [
    'driver' => 'bcrypt', // или 'argon2id'
    'bcrypt' => ['rounds' => env('BCRYPT_ROUNDS', 12)],
    'argon'  => ['memory' => 65536, 'threads' => 1, 'time' => 4],
];

// Хеширование при регистрации
$user->password = Hash::make($request->password);

// Проверка при логине
if (Hash::check($request->password, $user->password)) {
    // аутентифицирован
}

// Rehash при изменении cost — после успешного входа
if (Hash::needsRehash($user->password)) {
    $user->update(['password' => Hash::make($request->password)]);
}

После проверки пароля приложение должно «помнить», что пользователь аутентифицирован. Способа три: server-side sessions с cookie, stateless JWT, opaque tokens. У каждого свой профиль безопасности, удобства, масштабируемости. Правильный выбор зависит от архитектуры (монолит/микросервисы), типа клиента (браузер/SPA/мобайл), требований к revocation.

// config/session.php
return [
    'driver'         => 'redis',
    'lifetime'       => 120,           // 2 часа idle
    'expire_on_close'=> true,        // сессия умирает с закрытием вкладки
    'secure'         => true,         // cookie только по HTTPS
    'http_only'      => true,         // JS не имеет доступа
    'same_site'      => 'strict',      // защита от CSRF
];

Эти 5 настроек — обязательный минимум для session cookie в production. secure + http_only + same_site=strict покрывает 90% типичных атак на сессии.

JWT — три части через точку: header.payload.signature. Header описывает алгоритм, payload содержит claims (sub, exp, iat и кастомные), signature защищает целостность. JWT читаем (base64, не зашифрован) — не кладите туда секреты.

// Структура JWT
{"alg":"RS256","typ":"JWT"}                          // header
{"sub":"user_42","exp":1735689600,"role":"admin"}  // payload
<signature>                                              // HMAC или RSA

Алгоритмы подписи: HS256 (HMAC, симметричный, для одного сервиса), RS256 (RSA, асимметричный, для распределённых систем). RS256 предпочтительнее в микросервисах: один сервис подписывает приватным ключом, другие проверяют публичным.

// Создание токена
$token = $user->createToken('mobile-app', ['orders:read', 'orders:write']);
return ['token' => $token->plainTextToken()];

// Защита маршрутов
Route::middleware('auth:sanctum')->group(function () {
    Route::get('/api/me', fn (Request $r) => $r->user());
});

// Проверка ability
if ($request->user()->tokenCan('orders:write')) { ... }

// Revoke всех токенов
$user->tokens()->delete();

OAuth 2.0 — протокол делегированной авторизации: одно приложение получает разрешение действовать от имени пользователя в другом, без передачи пароля. OIDC (OpenID Connect) — надстройка над OAuth для аутентификации. Это два разных уровня: OAuth решает «может ли это приложение читать твоё API», OIDC — «кто этот человек».

1. Client → AS: GET /authorize?
     client_id=app&
     redirect_uri=https://app.com/callback&
     response_type=code&
     scope=openid profile email&
     code_challenge=<SHA256(verifier)>&
     code_challenge_method=S256&
     state=<random>

2. User логинится на AS, подтверждает scope

3. AS → Client: redirect to https://app.com/callback?code=<CODE>&state=<random>

4. Client → AS: POST /token
     grant_type=authorization_code&
     code=<CODE>&
     redirect_uri=...&
     client_id=app&
     code_verifier=<VERIFIER>

5. AS возвращает: {
     "access_token": "<JWT or opaque>",
     "refresh_token": "<opaque>",
     "id_token": "<JWT — OIDC only>",
     "expires_in": 3600
   }

Аутентификация отвечает «кто», авторизация — «что может». Модели авторизации различаются гранулярностью: RBAC (роли) подходит для большинства SaaS, ABAC (атрибуты) — для сложной бизнес-логики, ReBAC (отношения) — для соц-сетей и доступа к объектам по графу связей.

// composer require spatie/laravel-permission

// Назначить роль
$user->assignRole('editor');
$user->givePermissionTo('edit articles');

// Проверка
if ($user->can('edit articles')) { ... }
if ($user->hasRole('admin')) { ... }

// В route
Route::get('/admin', ...)->middleware('role:admin');
Route::get('/posts/edit', ...)->middleware('permission:edit articles');

// В Blade
@can('edit articles')
    <a href="...">Edit</a>
@endcan

Для ABAC-логики (свой/чужой пост) используйте Policies (см. KB_3 раздел Auth). Комбинация Spatie roles + Policies покрывает 95% задач.

CSRF — атака, при которой злонамеренный сайт заставляет браузер жертвы (уже авторизованной на целевом сайте) отправить запрос. Браузер автоматически прикрепляет cookie сессии — целевой сервер «верит» что это легитимный запрос пользователя. Защита — токен, который атакующий не может прочитать.

{{-- Blade: @csrf директива добавляет hidden input --}}
<form method="POST" action="/orders">
    @csrf
    <input name="product_id">
    <button>Buy</button>
</form>

// AJAX: токен из meta-тега + заголовок
<meta name="csrf-token" content="{{ csrf_token() }}">

// fetch / axios
fetch('/api/orders', {
    method: 'POST',
    headers: {
        'X-CSRF-TOKEN': document.querySelector('meta[name="csrf-token"]').content,
        'Content-Type': 'application/json',
    },
    body: JSON.stringify({...}),
});

Laravel middleware VerifyCsrfToken в группе web автоматически проверяет POST/PUT/PATCH/DELETE. API-маршруты (через Sanctum/JWT) не нужны в CSRF-защите, поскольку используют stateless токены.

XSS — внедрение JavaScript в страницу, отображаемую другим пользователем. JS исполняется в его браузере с правами вашего домена: читает cookie, session, делает запросы. Защита — правильное экранирование при выводе + Content Security Policy.

{{-- Безопасно: {{ }} экранирует HTML --}}
<div>{{ $comment->text }}</div>
{{-- <script>alert(1)</script> → &lt;script&gt;alert(1)&lt;/script&gt; --}}

{{-- Опасно: {!! !!} выводит как есть --}}
<div>{!! $comment->html !!}</div>

{{-- Если нужен HTML — санитизируйте через HtmlPurifier --}}
<div>{!! Purifier::clean($comment->html) !!}</div>

Content Security Policy — вторая линия. Заголовок указывает браузеру, откуда можно загружать скрипты:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com;
                          style-src  'self' 'unsafe-inline';
                          img-src    'self' data: https:;
                          object-src 'none'

Даже если XSS внедрился, без разрешения inline-скриптов он не выполнится. CSP меняет правила: атакующему нужно ещё обойти политику.

SQL Injection — внедрение SQL-кода через пользовательский ввод. Атакующий шлёт ' OR 1=1 -- в поле, оригинальный запрос становится SELECT * FROM users WHERE name = '' OR 1=1 --', возвращая всех пользователей. Защита одна и абсолютна: prepared statements. Конкатенация SQL с пользовательским вводом — всегда уязвимость.

// Уязвимо — конкатенация
$users = DB::select("SELECT * FROM users WHERE email = '" . $_GET['email'] . "'");

// Безопасно — параметр через ?
$users = DB::select('SELECT * FROM users WHERE email = ?', [$_GET['email']]);

// Eloquent — bindings автоматически
User::where('email', $_GET['email'])->first();

// DB::raw с пользовательским вводом — снова уязвимо
DB::table('users')->whereRaw("email = '" . $_GET['email'] . "'");

// DB::raw с bindings — безопасно
DB::table('users')->whereRaw('email = ?', [$_GET['email']]);

Eloquent защищает 100% случаев, если использовать parametr binding. Опасные точки: DB::raw, whereRaw, orderByRaw — при ручной конкатенации.

CORS — механизм, через который сервер разрешает (или запрещает) браузерам с других доменов делать запросы. По умолчанию same-origin policy запрещает чтение ответа на кросс-доменный запрос. CORS — контролируемое исключение. Неправильная настройка CORS = открытый API для любого сайта в интернете.

Классический пример: фронтенд на https://myfrontend.com, API на https://api.myapp.com. Без CORS браузер заблокирует AJAX-запрос. Чтобы разрешить, API должен вернуть Access-Control-Allow-Origin: https://myfrontend.com.

1. Конфиг — config/cors.php (в Laravel 7+ уже есть, для более старых нужен пакет fruitcake/laravel-cors):

return [
    'paths' => ['api/*', 'sanctum/csrf-cookie'],   // пути, для которых применяется CORS
    'allowed_methods'      => ['GET', 'POST', 'PUT', 'PATCH', 'DELETE'],
    'allowed_origins'      => ['https://myfrontend.com', 'http://localhost:3000'],
    'allowed_origins_patterns' => [],
    'allowed_headers'      => ['*'],
    'exposed_headers'      => [],
    'max_age'             => 3600,   // кеш preflight
    'supports_credentials'=> true,   // для cookie-auth (Sanctum SPA)
];

2. Middleware — в глобальный стек. В Laravel 10 — App\Http\Kernel::$middleware. В Laravel 11+ — в bootstrap/app.php:

// bootstrap/app.php (Laravel 11+)
->withMiddleware(function (Middleware $middleware) {
    $middleware->api(prepend: [
        Illuminate\Http\Middleware\HandleCors::class,
    ]);
})

Middleware автоматически обрабатывает OPTIONS-запросы (preflight) и добавляет нужные заголовки в ответы.

Rate limiting — ограничение числа запросов от одного источника за интервал времени. Защищает от: brute-force паролей, credential stuffing, scraping, DDoS уровня приложения, перегрузки API. Без rate limiting один скрипт с одной машины может потушить ваш сервис или перебрать миллионы паролей.

// routes/web.php
Route::post('/login', LoginController::class)
    ->middleware('throttle:5,1'); // 5 попыток в минуту с IP

// API с лимитом на user
Route::middleware(['auth:sanctum', 'throttle:60,1'])->group(function () {
    Route::apiResource('orders', OrderController::class);
});

// Кастомный лимит — RouteServiceProvider boot()
RateLimiter::for('login', function (Request $request) {
    return [
        Limit::perMinute(5)->by($request->input('email')),
        Limit::perMinute(30)->by($request->ip()),
    ];
});

Лучшая практика для login: лимит и по email, и по IP. Защищает от перебора паролей одного пользователя и от credential stuffing с одного источника.

TLS — криптографический протокол, обеспечивающий три свойства: конфиденциальность (никто посередине не читает), целостность (никто не изменил), аутентичность сервера (это действительно тот, кем себя называет). Без TLS любой Wi-Fi в кафе видит ваши пароли. Современный стандарт — TLS 1.3, минимум приемлемо — TLS 1.2.

# nginx config
server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols         TLSv1.2 TLSv1.3;
    ssl_ciphers           ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
    ssl_prefer_server_ciphers on;
    ssl_session_cache     shared:SSL:10m;
    ssl_session_tickets   off;

    # HSTS
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}

# HTTP → HTTPS редирект
server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Security headers — HTTP-заголовки, инструктирующие браузер усиливать защиту. Это дешёвая защита: одна строка конфига даёт многократно сложнее атаки. Чек-лист, который должна пройти любая production-страница: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.

final class SecurityHeaders
{
    public function handle(Request $request, Closure $next): Response
    {
        $response = $next($request);

        $response->headers->add([
            'Strict-Transport-Security'   => 'max-age=31536000; includeSubDomains; preload',
            'X-Frame-Options'             => 'DENY',
            'X-Content-Type-Options'      => 'nosniff',
            'Referrer-Policy'             => 'strict-origin-when-cross-origin',
            'Permissions-Policy'          => 'camera=(), microphone=(), geolocation=()',
            'Content-Security-Policy'     => "default-src 'self'; script-src 'self' 'nonce-{$nonce}'; img-src 'self' data: https:;",
        ]);

        return $response;
    }
}

Готовый пакет: bepsvpt/secure-headers — конфиг + middleware. Тест собственных заголовков — securityheaders.com.

Секреты (API-ключи, DB-пароли, JWT-секреты, OAuth client_secret) не должны храниться в коде. Гит-история помнит навсегда; удалённые из последнего коммита секреты остаются в истории, доступны через git log -p. Современная практика: переменные окружения для dev, секреты-менеджер (Vault, AWS Secrets Manager) для prod.

• .env в .gitignore и в .dockerignore;
• .env.example со всеми ключами без значений — в git;
• Pre-commit hook сканирует коммиты на secrets (git-secrets, gitleaks, trufflehog);
• В CI — secrets через защищённые переменные (GitHub Secrets, GitLab CI variables);
• На production — не .env, а env vars через secrets manager;
• Rotate секретов после ухода каждого сотрудника, после инцидента;
• Принцип наименьших привилегий: каждый сервис имеет только свои ключи.

Разработчик принёс на ревью endpoint загрузки аватарки. Сделаем поэтапный security-review, отмечая уязвимости.

// Множество проблем — найдите все
final class AvatarController
{
    public function upload(Request $request)
    {
        $user = User::find($request->input('user_id'));
        $file = $request->file('avatar');
        $name = $file->getClientOriginalName();
        $file->move(public_path('avatars'), $name);
        $user->update(['avatar' => "/avatars/{$name}"]);
        return ['url' => "/avatars/{$name}"];
    }
}

final class AvatarController
{
    public function __construct(private AvatarUploader $uploader) {}

    public function upload(UploadAvatarRequest $request): JsonResponse
    {
        $path = $this->uploader->store($request->user(), $request->file('avatar'));

        return response()->json(['url' => route('avatar.show', ['path' => $path])]);
    }
}

// FormRequest решает: auth + validate
final class UploadAvatarRequest extends FormRequest
{
    public function authorize(): bool { return $this->user() !== null; }

    public function rules(): array
    {
        return [
            'avatar' => ['required', 'image', 'mimes:jpg,png,webp', 'max:2048', 'dimensions:max_width=2000,max_height=2000'],
        ];
    }
}

// Маршрут с throttle
Route::post('/avatar', [AvatarController::class, 'upload'])
    ->middleware(['auth:sanctum', 'throttle:5,60']); // 5 загрузок в час