Модел за сигурност

Граница на доверие

Браузърът може да заяви и покаже TrueSift challenge, но не е авторитет за защитеното бизнес действие. Като контролиран от клиента proof input се приема единствено непрозрачният verificationToken.

Плъгинът подписва action, path и origin в краткоживеещ WordPress context token. PHP валидира подписа и изпраща получените сървърни очаквания заедно със Site Key, Secret Key и Verification Token към авторитетния TrueSift proof endpoint.

Приет proof

Нормален proof се приема само когато TrueSift response потвърди всички следващи условия:

• allowed е true;
• decision е allow;
• еднократната консумация е потвърдена чрез consumed: true или непразен consumedAt;
• налични са challenge ID, action и origin;
• върнатите action, path и origin съвпадат с подписания WordPress контекст.

Невалидни, изтекли, повторно използвани, несъответстващи, оценени с review и блокирани proofs никога не използват fail-open.

Политика при недостъпност

Само запазената сървърна настройка fail_open или константата TRUESIFT_FAIL_OPEN може да позволи защитено действие, когато proof услугата временно не е достъпна. Browser поле с име failOpen се игнорира.

Submit контролът в браузъра продължава да изисква издаден Verification Token. Следователно browser challenge или verify грешка не отключва формата само защото server-side fail-open е активиран.

Credentials

• Site Key и Secret Key никога не присъстват във frontend конфигурацията.
• Secret Key се съхранява криптирано със Sodium secretbox, когато е наличен.
• Като fallback се използва OpenSSL AES-256-GCM.
• Константи в wp-config.php могат да се използват вместо съхранение в базата данни.
• Logs никога не съдържат credentials или пълни Verification Tokens.
• HTTP certificate verification никога не се изключва.

Докладване на уязвимост

Не публикувайте проблеми със сигурността в публична support тема. Докладвайте ги чрез контакта за сигурност:

mailto:info@webdigitech.de