Specifications

1. CSRF Protection

Cross-Site Request Forgery (CSRF) tokens ensure that form submissions come from your own website and not malicious third parties. A unique token is generated per user session and checked on form submission. If the token is missing or invalid, the request is rejected.

2. Honeypot Field

An invisible form field named website is included but hidden from human users. Bots that auto-fill all fields will likely fill this too. If this field is filled, the submission is flagged as spam and rejected.

3. Rate Limiting

Submissions from the same IP address are limited to prevent spam and abuse. The form enforces the following limits:

  • Maximum 5 submissions per 60 seconds
  • Maximum 10 submissions per 2 minutes (triggering a short block)
  • Maximum 100 submissions per 24 hours

If these limits are exceeded, the form rejects the submission with an explanatory message. In addition to these basic limits, advanced rate limiting can be implemented, such as blocking repeated submissions with identical content or from suspicious user agents.

4. CRLF Injection Prevention

The form checks input fields such as name, email, and subject for carriage return (\r) or newline (\n) characters, which are often used in email header injection attacks. Any input containing these characters is rejected immediately.

5. Input Validation & Sanitization

All fields are validated to ensure correct format and presence:

  • Name, Subject, Message: must not be empty.
  • Email: must be a valid email address.
  • Phone: must only contain digits, spaces, or plus signs.

All inputs are trimmed and sanitized to avoid injection and formatting issues.

6. Spam Keyword Filtering

The form checks the combined inputs (name, subject, message, and email) for common spam keywords such as “viagra”, “free money”, “casino”, and others. If detected, the submission is rejected to prevent spam content.

7. Error Reporting and Handling

Errors are handled gracefully and, during development, PHP error reporting is enabled for troubleshooting. In production, error display should be disabled for security. Any invalid or suspicious input results in immediate rejection with minimal information disclosed.

8. Session Security

Sessions are used to securely store CSRF tokens and maintain state between form generation and submission, preventing tampering or replay attacks.

9. Header Injection Check in Email Inputs

Email input fields are checked to block injection attempts that include suspicious characters such as carriage returns (\r), newlines (\n), or colons (:). This helps prevent malicious alteration of email headers during form submission.

10. Language and Content Filtering

The form employs filtering to detect and block spammy keywords and suspicious content patterns. This filtering is customizable to suit the needs of your target audience and help reduce unwanted or harmful submissions.

11. Non-Latin Character Blocking with Greek Allowed

To further reduce spam and injection risks, the form blocks characters outside of Latin and Greek alphabets. This means that inputs with non-Latin characters (except Greek) are rejected, ensuring only expected character sets are accepted.

12. JavaScript Token Validation (Optional)

Optionally, the form can implement client-side JavaScript token validation to help distinguish bots from legitimate users. This involves generating and verifying tokens via JavaScript before form submission.

Summary

This multi-layered security approach protects the contact form from automated abuse, spam, injection attacks, and forgery. It combines input validation, rate limiting, token verification, and spam filtering to ensure only legitimate messages are processed.