Кратко и по существу.
Что делает `transient`
- Поле помеченное `transient` не записывается в поток стандартной Java‑сериализации.
- При десериализации поле получает значение по умолчанию: для ссылочных типов — `null`, для примитивов — $0$ или $false$. Это значит, что `password` после десериализации будет отсутствовать в потоке и, если не восстановлен вручную, станет `null`.
- Ограничения: `transient` не шифрует и не удаляет значение из памяти/дампов/логов; если есть пользовательский `writeObject`/`readObject` или другие поля/методы, секрет всё ещё может быть сохранён/слит.
Основные проблемы безопасности Java‑сериализации
- Десериализация недоверенных данных — риск выполнения произвольного кода (gadget‑цепочки) и RCE. Очень частая и серьёзная уязвимость.
- Отсутствие целостности и конфиденциальности: данные в потоке могут быть изменены или прочитаны, если не использовать подпись/шифрование.
- Утечки секретов: сериализуемые объекты или побочные поля/методы могут сохранять секреты; значения остаются в памяти и дампах.
- Проблемы совместимости и атак на конструкторы/инициализацию объектов (сбои, неожиданные состояния).
- Библиотечные уязвимости: даже если ваши классы безопасны, сторонние классы в classpath могут дать вектор атаки.
Рекомендации при работе с сериализацией
- Не десериализуйте данные от недоверенных источников.
- Отключите или ограничьте Java‑сериализацию, если можно.
- Если нужно — применяйте ObjectInputFilter (Java $9+$) или собственные фильтры allowlist/denylist.
- Подписывайте/шифруйте сериализованные данные (MAC + шифрование) перед хранением/передачей.
- Минимизируйте класс‑патчи в classpath и не давайте десериализации классов, которые не нужны.
- Помечайте чувствительные поля `transient` и дополнительно очищайте массивы после использования (см. ниже).
Безопасные альтернативы для хранения сессий и секретов
Сессии
- Серверная сессия: хранить состояние на сервере (Redis, Memcached, база данных). В cookie — только короткий случайный идентификатор с флагами HttpOnly, Secure, SameSite.
- Токены доступа: использовать reference‑tokens (короткий идентификатор), а не самодостаточные длительные сериализованные объекты.
- JWT только при необходимости: использовать короткий TTL, подписывать (JWS) и/или шифровать (JWE). Не храните в JWT чувствительные данные.
- Практики: ротация ID при логине, инвалидизация при логауте, защита от CSRF, минимальные привилегии.
Секреты (пароли, ключи, токены)
- Использовать специализированные хранилища: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HSM.
- На хосте: Java KeyStore (JKS/PKCS12) или OS keyring/PKCS#11/HSM с доступом по минимальным правам.
- Не хранить секреты в репозитории кода; передавать через защищённые переменные окружения/secret injection при деплое.
- В памяти: хранить пароли в `char[]` и перезаписывать содержимое после использования, избегать `String` для секретов.
- Логи/дампы: исключать секреты из логов, защищать дампы памяти и swap, включать шифрование диска.
Если сериализация неизбежна
- Не использовать java.io.Serializable по умолчанию; предпочесть безопасные форматы (JSON с явной схемой/списком типов, Protobuf, CBOR) и явную десериализацию.
- Если нужно сериализовать объекты с секретами — шифровать эти поля в `writeObject` и дешифровать в `readObject`, и всё равно избегать доверия входным данным.
- Применять фильтры классов и проверку версии/контракта объектов.
- Логику безопасности держать вне сериализуемых структур: хранить только ссылки/идентификаторы, реальные секреты — в защищённом хранилище.
Краткий вывод
- `transient` предотвращает попадание поля в поток, но не решает всех проблем безопасности.
- Избегайте десериализации недоверенных данных; лучше перейти на безопасные схемы хранения сессий и централизованные секрет‑менеджеры.