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.
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.
Submissions from the same IP address are limited to prevent spam and abuse. The form enforces the following limits:
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.
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.
All fields are validated to ensure correct format and presence:
All inputs are trimmed and sanitized to avoid injection and formatting issues.
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.
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.
Sessions are used to securely store CSRF tokens and maintain state between form generation and submission, preventing tampering or replay attacks.
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.
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.
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.
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.
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.