票選系統的做法可以拆成四步：先寫好投票辦法，明訂誰能投、每人能投幾票、投票期間與異常票怎麼處理；再依活動規模選擇身分驗證方式，例如 Email 驗證、手機簡訊驗證、LINE Login 或會員登入；接著把每一票都寫在伺服器端，搭配頻率限制與機器人辨識；並保留完整的投票紀錄，讓結果在公布前可以稽核。防灌票沒有單一做法能完全擋住，目標是提高重複投票的成本，並讓異常有跡可循。
先寫投票辦法：規則決定系統怎麼做
系統的每個設定都來自投票辦法，辦法沒寫清楚，系統就只能猜。動工前先把下列項目定下來：
| 規則項目 | 要決定的內容 | 系統對應的設計 |
|---|---|---|
| 投票資格 | 所有人、會員，或員工、學員等指定名單 | 驗證方式與名單匯入 |
| 票數規則 | 每人一票、每日一票，或可投多位候選但同一候選限一票 | 以投票者身分為單位計數與限制 |
| 投票期間 | 開始與截止的日期、時間與時區 | 以伺服器時間判斷，不用投票者裝置的時間 |
| 票數顯示 | 即時公開、只顯示排序，或截止後才公布 | 前台顯示與資料介面的權限 |
| 異常票處理 | 判定方式、是否扣除、申訴管道 | 紀錄保存與標記功能 |
| 結果公布 | 公布時間、方式與得獎者聯繫 | 投票鎖定與結果匯出 |
辦法公告後若需要修改，要公告修改內容與生效時間，系統也要記錄規則變更的時間。票選若搭配抽獎送贈品，抽獎的公平性與名單處理可另外參考抽獎活動平台的整理。
身分驗證方式怎麼選
一人一票能不能做到，取決於系統用什麼認定「同一個人」。常見方式的差異如下：
| 方式 | 辨識同一人的能力 | 投票門檻 | 適合情境 |
|---|---|---|---|
| 不驗證，只記在瀏覽器 | 低，Cookie 值預設可被使用者看到並修改 | 低 | 不送獎品的人氣投票 |
| Email 驗證連結 | 中，一人可能有多個信箱 | 中 | 一般品牌活動 |
| 手機簡訊驗證碼 | 較高，要取得多個門號比信箱困難 | 中 | 有獎品的公開票選 |
| LINE Login | 中至較高，同一提供者下使用者 ID 固定 | 低 | 已經營 LINE 官方帳號的品牌 |
| 會員帳號或指定名單 | 高，名單由主辦方掌握 | 視註冊流程而定 | 員工、學員或會員限定投票 |
LINE 的使用者 ID 依提供者不同，票選系統要和既有的 LINE 會員資料放在同一個提供者下，才能對應到同一人。
自建驗證時，驗證碼與驗證連結要一次有效、設有效期限，並以密碼學安全的亂數產生；MDN 說明 Math.random() 不提供密碼學安全的亂數，不要用於安全相關用途，應改用 Web Crypto API 的 Crypto.getRandomValues()，伺服器端也要用對應的安全亂數函式。
票選系統的建置步驟
- 建立候選資料：名稱、圖片與介紹，投票開始後鎖定，不再修改。
- 設定規則參數：投票期間、每人票數、每日重置的時間點，一律用伺服器時間判斷。
- 串接身分驗證，取得穩定的投票者識別，例如會員編號、LINE 使用者 ID，或驗證過的手機與信箱。
- 投票寫入伺服器資料庫，並在資料庫層設定「同一投票者、同一候選、同一期間」不可重複的限制，避免同時送出兩次都被計入。
- 決定票數顯示方式，以及前台統計多久更新一次。
- 加上頻率限制與機器人辨識，做法見下一節。
- 上線前測試：重複投票、兩個分頁同時送出、截止時間前後各投一次，並用手機與不同瀏覽器走完流程。
- 截止後關閉投票功能，匯出投票紀錄與統計結果存檔，再進行複核與公布。
驗證是否成功的標準是：重複的票被拒絕且有明確訊息、同時送出只計一票、截止後的票全部無效。
防灌票的三層原理：身分、頻率與行為
OWASP（Open Worldwide Application Security Project）把這類行為歸在自動化威脅中的 Skewing：以重複點擊、請求或送出表單來改變某項指標，舉例就包括投票結果。防範的原理可以分成三層：
身分：每一票綁定經過驗證的身分
灌票者必須取得更多身分才能多投，驗證方式越難大量取得，重複投票的成本就越高。
頻率：在伺服器端限制請求次數
限制同一來源在一段時間內能送出幾次請求，超過時可以回應 HTTP 429（Too Many Requests），並附上 Retry-After 標頭告知多久後再試。MDN 說明頻率限制通常以用戶端 IP 為依據，已驗證身分或帶有 Cookie 時也可以針對個別使用者。同一公司、學校或行動網路的使用者可能共用對外 IP，所以 IP 的門檻要放寬，嚴格的限制放在身分上。
行為：用機器人辨識服務評估風險
以 Google 的 reCAPTCHA 為例，官方文件說明它已成為 Google Cloud Fraud Defense 的一部分：前端取得的權杖要送到後端評估，結果包含介於零到一之間的分數，越接近一代表風險越低，越接近零代表風險越高。官方說明可以先不採取動作，觀察流量後再決定門檻，並建議在背景處理，而不是直接阻擋流量。套用到票選，可以把低分的票標記待審，或要求額外驗證。
紀錄稽核與異常票處理
投票紀錄是處理爭議的依據。參考 OWASP 的紀錄建議，每筆紀錄要能回答何時、何處、何人與做了什麼：投票時間、來源 IP 與裝置資訊、投票者識別、投給哪位候選、驗證結果與機器人辨識分數。驗證碼、存取權杖與密碼不要寫進紀錄。紀錄要能偵測竄改，並盡快複製一份唯讀備份。
以下情況可以列為複核訊號，而不是直接判定灌票：短時間內集中湧入的票、同一來源出現大量不同帳號、新建立的帳號集中投同一位候選、驗證碼請求次數遠多於成功投票的次數。處理流程是先標記、保留原始紀錄，由人工複核後，依公告的辦法決定是否扣除，記錄理由並在公布結果時一併說明。辦法沒有寫到的處理方式，臨時採用容易引起爭議。
投票者個資：只收驗證需要的欄位
票選活動一旦要求手機、信箱或會員資料，就是在蒐集個人資料。個人資料保護法第八條規定，向當事人蒐集時應明確告知蒐集者名稱、蒐集目的、個人資料類別、利用的期間、地區、對象及方式、當事人可行使的權利及方式，以及不提供對其權益的影響，這些可以寫在投票頁的告知事項與隱私權政策中。
欄位以完成驗證所需為限，寄送獎品的地址等資料，只在確定得獎後向得獎者收集。公布結果時遮蔽投票者與得獎者的部分資訊，活動結束後依辦法寫明的期限刪除不再需要的資料。個資法的適用，以主管機關公告或專業意見為準。
常見問題
投票一定要登入或驗證嗎？
要看活動有沒有獎品與爭議風險。純娛樂的人氣投票可以只做頻率限制；有獎品或代表正式結果的票選，建議要求驗證身分，並在辦法中寫明驗證方式。
票數要即時公開嗎？
兩種做法都可以，重點是在辦法中事先寫明。選擇截止後才公布時，系統要確保隱藏期間的票數不會從前台頁面或資料介面外流。
截止時間到了，還停在投票頁的人怎麼處理？
以伺服器收到投票的時間判斷是否有效，不用投票者裝置的時間。截止後送出的票要回應明確訊息，頁面也要改為已截止，避免投票者以為投票成功。
可以讓同一人每天投一票嗎？
可以，在辦法中寫明每日一票，以及每日重置的時間點與時區。系統以伺服器時間判斷是否已跨過重置點，再開放下一票，不依賴投票者裝置的時間。
投票時顯示請求過多是什麼意思？
代表伺服器的頻率限制被觸發，短時間內送出太多請求，稍等一段時間再試即可。主辦方若接到大量反映，要檢查門檻是否設得太嚴，例如共用網路的投票者被一起擋下。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
規劃票選活動時，先把投票辦法、投票資格與驗證方式定下來，再決定活動頁與後台。京采能協助規劃票選活動頁與投票後台，串接會員、LINE Login 或簡訊驗證，在伺服器端設定投票限制、頻率限制與稽核紀錄，活動結束後匯出結果。服務內容可參考網頁設計服務，或聯絡我們討論活動規模與時程。
