Rule Details

Terms of Service (ToS), also called Terms and Conditions or Terms of Use, define the legal relationship between your service and its users. They sit alongside disclosures users reasonably need before acting, which is why both the FTC disclosure guidance (opens in new tab) and GDPR Article 13 (opens in new tab) push teams toward visible, accessible legal information rather than burying it.

Code Example

<footer>
  <nav aria-label="Legal">
    <ul>
      <li><a href="/terms">Terms of Service</a></li>
      <li><a href="/privacy">Privacy Policy</a></li>
      <li><a href="/cookies">Cookie Policy</a></li>
    </ul>
  </nav>
  <p>&copy; 2025 Example Corp. All rights reserved.</p>
</footer>

Why It Matters

Terms of Service protect your business by limiting liability, establishing jurisdiction, setting rules for user conduct, and specifying your rights to user-generated content — but only if users could reasonably discover and read them.

When You Need Terms of Service

Enforceable Acceptance: Clickwrap vs Browsewrap

Browsewrap (Weak — Link Only)

Simply linking to terms without requiring acknowledgment. Courts have found these difficult to enforce because users may not have seen them:

<!-- Browsewrap — weak legal enforceability -->
<footer>
  <a href="/terms">Terms of Service</a>
</footer>

Clickwrap (Stronger — Explicit Acceptance)

Requiring a checkbox during signup makes it harder to claim the user was unaware of the terms:

<!-- Clickwrap during registration — stronger enforceability -->
<form method="POST" action="/register">
  <input type="text" name="email" placeholder="Email" required>
  <input type="password" name="password" placeholder="Password" required>
 
  <label>
    <input type="checkbox" name="terms_accepted" required>
    I agree to the
    <a href="/terms" target="_blank" rel="noopener noreferrer">Terms of Service</a>
    and
    <a href="/privacy" target="_blank" rel="noopener noreferrer">Privacy Policy</a>
  </label>
 
  <button type="submit">Create account</button>
</form>

// Server: record acceptance
const termsAccepted = formData.get('terms_accepted')
if (!termsAccepted) {
  return Response.json({ error: 'You must accept the terms' }, { status: 400 })
}
 
// Store acceptance with timestamp and version
await db.user.create({
  data: {
    email,
    passwordHash,
    termsAcceptedAt: new Date(),
    termsVersion: '2025-01-15', // Current version date
  }
})

Terms URL Conventions

Use a stable, predictable URL:

https://example.com/terms
https://example.com/terms-of-service
https://example.com/legal/terms

Store the current version date in the document and in your database so you can notify users when terms change and re-obtain consent if required.

Key Clauses in Terms of Service

Exceptions

• Scanner output, leaked-secret detections, or stack traces should be confirmed as production-relevant before being escalated as blockers.
• Archived dependencies, sample values, or test fixtures can create false positives, but they should still be documented and bounded clearly.
• If multiple findings overlap, prioritize the issue that most directly enables compromise or data exposure.

Verification

Automated Checks

• Test the affected flow in a production-like environment, not just local development.
• Document any intentional exceptions explicitly.

Manual Checks

• Inspect the final HTTP response or browser behavior to confirm the control is actually enforced.
• Verify third-party integrations or embeds still work after the restriction is applied.