Are maritime sites really targeted?

Yes. Sanctioned-trade probing, BEC attacks targeting payment workflows, supply-chain reconnaissance and credential harvesting all show up in maritime web traffic. The sector's reputation for slower digital adoption makes it more attractive, not less.

Is a managed WordPress host enough?

Necessary but not sufficient. Kinsta, WP Engine and Rocket.net give you a strong baseline (server-level WAF, daily backups, automated updates). The application-level work (plugin discipline, role hardening, form protection) still has to happen on top.

How often should the security baseline be reviewed?

Quarterly, with a documented checklist that covers plugin audit, user-account review, backup restore test, header configuration check and SPF/DKIM/DMARC verification. A site that hasn't had a security review for 18 months is almost always carrying drift; the review takes a day and prevents the avoidable incidents.

WordPress security hardening for maritime sites with public RFP forms

A WordPress site for a ship management company, port authority or marine insurance broker is a high-value target in a low-noise sector. Public-facing forms (RFP, quote request, broker enquiry, careers application) accept untrusted input from the open internet. Vendor pages list named clients. Contact pages reveal staff details that feed BEC playbooks. The combination is attractive to the people who do this for a living.

Most maritime WordPress sites we audit have at least three serious security gaps that should never have shipped. The fixes are well understood. The work just doesn’t get done.

The baseline that should be non-negotiable

Hosting layer

Managed WordPress hosting (Kinsta, WP Engine, Rocket.net, WordPress.com VIP for the largest). These providers handle server-level WAF, DDoS protection, isolated environments, automatic security patching and proper backup retention. Cheap shared hosting is wrong for a serious maritime corporate site, regardless of plugin discipline.

TLS 1.2 minimum, TLS 1.3 preferred. No SSLv3, no TLS 1.0, no TLS 1.1. Modern browsers will warn or block; modern partners will deduct points on procurement.

HSTS enabled with preload, after you’re confident HTTPS won’t break. Once enabled, you’re committed.

Strict CSP, COEP and CORP headers where the build allows. Most maritime sites ship with permissive headers because someone didn’t want to chase a Content-Security-Policy report. The cost is a category of XSS attacks that didn’t need to be possible.

Application layer

WordPress core auto-updates enabled for minor releases. Major releases tested and applied within 30 days.

Plugin discipline. Fewer than 20 active plugins. Every plugin from a maintained source. No plugins downloaded from third-party sites or unofficial sources. Quarterly review of installed plugins; remove anything not actively used.

Theme discipline. Either a hand-coded theme or a well-maintained commercial theme with active support. Avoid free themes from non-reputable directories; many have included backdoors over the years.

WP-Admin protection.

Move /wp-admin and /wp-login.php behind a custom path or HTTP basic auth (or a proper SSO if you have it).
Limit login attempts (WP Limit Login Attempts, Wordfence, or hosting-level rate limits).
Two-factor authentication required for every administrator and editor account.
No default admin username anywhere.
Strong password policy enforced by plugin.

File permissions and directory protection.

wp-config.php permissions 600 or 640.
xmlrpc.php disabled unless specifically needed (rarely is, in 2026).
Directory listing disabled at server level.
File editing in WP-Admin disabled (define('DISALLOW_FILE_EDIT', true) in wp-config.php).

Form-specific protection

This is where most maritime sites get hit. Public RFP and contact forms are convenient targets for spam, credential probing, BEC reconnaissance and occasionally exploit attempts.

Rate limiting. Per-IP submission limits at the application or CDN level. Five submissions in five minutes is generous for human users.

Anti-bot. Cloudflare Turnstile or hCaptcha invisible. Avoid Google reCAPTCHA v2 (the click-the-boats one) for usability and accessibility reasons. Don’t rely solely on honeypot fields; modern bots fill them.

Server-side validation. Email format, length limits, character set restrictions. Reject obvious garbage at validation, not at processing.

No file uploads on the public form unless the form genuinely requires it (CV upload on careers, drawing upload on quote forms). Where uploads are needed, restrict by mime type, scan with ClamAV or VirusTotal API, store outside the public webroot, never executable.

Email handling. Form submissions sent via SMTP authentication, not raw mail(). SPF, DKIM and DMARC configured on the sending domain (a worryingly common gap). The forms should land in a CRM, not just an inbox; CRMs are easier to audit when something goes wrong.

Payment and finance touchpoints

If your site handles any payment workflow (event registration, training course booking, port dues), keep card data out of WordPress entirely. Use Stripe, GoCardless or a similar provider with redirect-based or hosted-fields integration. PCI-DSS scope creeps into WordPress only if you let it.

For maritime sites that publish bank details for invoicing (still common), assume those pages are scraped daily by BEC attackers. Use a noindex and rate-limit aggressively, or put bank details behind authentication.

What backups should actually look like

A backup that you’ve never restored is a backup you don’t know works. The baseline:

Daily automated backups, retained 30 days.
Weekly backups retained 12 weeks.
Monthly backups retained 12 months.
Backups stored offsite (different cloud, different account).
A documented restore procedure tested at least once a year.

We’ve watched maritime sites get hit and discover that their backup strategy was “the host has them somewhere”. The host did, technically, but in the same account that the attacker had compromised. The restore took five days.

Monitoring and incident response

Activity logging of administrator actions (WP Activity Log or equivalent). When something goes wrong, you need to know what was changed and by whom.

Uptime monitoring with alerting. A site offline for two hours during a procurement evaluation is a deal you didn’t know you lost.

Documented incident response. Who gets called when the site is hit? Who has access to hosting, DNS, the WAF, the CMS? A maritime corporate site is on most weeks not a high-stakes operation, but on the week it’s compromised, the difference between four hours and four days of recovery is whether anyone wrote down the response plan.

Three quick checks on your current site

Three quick checks:

Try yourdomain.com/wp-admin. Does it bring up the standard WordPress login page directly? That’s a fail.
View source on the homepage. Does the WordPress version appear in the generator meta? That’s a fail.
Submit your contact form with a typo and refresh the page. Does the form re-submit on refresh? That’s a fail.

Three small fixes that close real attack surface. A maritime corporate site can be hardened to a defensible baseline in a week of focused work, then maintained on a quarterly review cadence. The work isn’t glamorous but the alternative is finding out the hard way.