小程序簽約看起來輕巧方便，掃個碼、按個手印就完成一份合同，可正是這種「輕」，讓很多安全隱患藏得很深。我看過不少用 FastAdmin 這類框架加插件搭起來的電子合同系統，功能都不錯，但真正上線後出問題的地方，往往不是簽章演算法，而是那些看起來無關緊要的配置細節。
前端配置暴露帶來的越權風險
最典型的例子就是 siteinfo.js 這種配置檔。裡面通常放著 siteroot、tenant_id，而小程序的前端包是可以被反編譯的——這幾乎沒有難度，市面上的工具幾分鐘就能把 wxapp 目錄還原出來。假設某個系統把 tenant_id: 1 寫死在前端，而後端又只憑這個參數決定「你屬於哪家企業」，那攻擊者把它改成 2、3、4 會發生什麼？如果服務端沒有做 token 與租戶的綁定校驗，這就是一條直通別家企業合同列表的路。
所以我一向建議：租戶識別可以由前端傳，但必須在服務端用登入態二次確認。前端傳的所有東西，都當成不可信輸入來處理。
合法域名與傳輸層的疏忽
微信要求正式環境的 request、uploadFile、downloadFile 都配置 HTTPS 合法域名，這其實是幫了大忙。但開發階段那個「不校驗合法域名」的勾選框，是我見過最常被忘記關掉的東西。更糟的是有些團隊為了省事，直接用自簽憑證或者過期憑證，導致中間人攻擊有了空間——合同這種東西一旦在傳輸中被替換，後果不只是資料洩漏，是法律責任。
合同 PDF 的下載連結也值得單獨說。如果檔案存在 public 目錄下、URL 是 contract_1001.pdf 這種可預測命名，那麼枚舉就是必然的。合同附件應該走鑑權介面 + 臨時簽名 URL，有效期控制在幾分鐘內比較穩妥。
簽署意願與身分真實性
技術之外還有一層更麻煩的問題：怎麼證明簽的人真的是他本人？依《電子簽名法》關於可靠電子簽名的要求，簽名製作資料需專屬於簽署人並由其控制，簽署後的任何改動都要能被發現。實務上意味著什麼呢——實名認證、人臉核身、短信驗證碼、簽署時間戳存證，這幾道最好都留下日誌。
短信驗證碼那塊還有個容易被忽略的點：介面沒做頻率限制，就等於幫人準備了一個轟炸機，帳單能讓人心疼半天。
存證鏈條的完整性
最後聊一個常被當成「以後再說」的事：哈希存證。合同簽完後對檔案做 SHA-256 並把摘要落庫、有條件的話上鏈或送第三方時間戳服務，這樣哪怕日後資料庫被改，也還有比對依據。很多糾紛最終打的不是有沒有簽，而是簽的到底是哪一版。
說到底，小程序簽約的安全不是某個模組的事，它是從前端配置、傳輸、儲存、鑑權一路到存證的完整鏈條。任何一環偷懶，整條鏈的可信度都要打折。
評論（9）
那個tenant_id被改掉的例子太真實了，很多開發者真的會忘了後端校驗
PDF路徑如果能被猜到真的很恐怖，得趕快檢查一下公司的系統
人臉核身這塊現在門檻高嗎？實作起來複雜不複雜
確實，很多時候開發環境的設定忘了關，上線就變漏洞
哈希存證這點很重要，不然真的沒辦法證明合同沒被篡改
短信介面沒限流真的會被刷爆，之前公司就被搞過一次
感覺電子簽約最麻煩的還是法律效力的認定，技術只是其中一部分
臨時簽名URL這個建議很實用，確實比直接放public目錄安全多了
反編譯現在這麼方便，前端真的不能放任何敏感資訊