press.bungee.host

What is this?

CAA (Certification Authority Authorization) is a DNS record that specifies which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for your domain.

Why does it matter?

Without CAA records, any of the hundreds of trusted CAs worldwide can issue a certificate for your domain. A compromised or rogue CA could issue a fraudulent certificate for your domain, enabling MITM attacks. CAA limits this risk to your chosen CA(s).

How to fix it

Add CAA records to your DNS. Example for Let\'s Encrypt only: 0 issue "letsencrypt.org" For multiple CAs (e.g. Let\'s Encrypt + DigiCert): 0 issue "letsencrypt.org" 0 issue "digicert.com" To also allow wildcard certificates: 0 issuewild "letsencrypt.org" For email notifications on unauthorized issuance attempts: 0 iodef "mailto:security@yourdomain.com" Check current CAA records at: sslmate.com/caa

What is this?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The signature is created with a private key on your mail server and verified by recipients using a public key published in DNS.

Why does it matter?

DKIM proves that an email actually came from your mail server and was not modified in transit. Without DKIM, anyone can send emails that appear to be from your domain (spoofing), and DMARC alignment checks will fail even if SPF passes.

How to fix it

DKIM is configured in your email provider, not directly in DNS. Here is the process: 1. Generate a DKIM key pair in your email provider: - Google Workspace: Admin console → Apps → Gmail → Authenticate email - Microsoft 365: Admin center → Settings → Domains → DKIM - Mailchimp/SendGrid/Mailjet: Each has a DKIM setup page in their dashboard 2. Copy the TXT record they provide and add it to your DNS: Name: selector._domainkey.yourdomain.com Value: v=DKIM1; k=rsa; p=MIGf... 3. Activate DKIM signing in your provider after publishing the DNS record. The selector name (e.g. 'google', 'selector1') comes from your email provider.

What is this?

MTA-STS (Mail Transfer Agent Strict Transport Security) is a standard that forces other mail servers to use encrypted TLS connections when delivering email to your domain. Without it, a network attacker could silently strip TLS from email in transit.

Why does it matter?

Email is delivered between servers using SMTP. By default, SMTP tries TLS but falls back to plaintext if TLS is not available — a downgrade attack. MTA-STS prevents this fallback, ensuring all email delivered to your domain is encrypted in transit.

How to fix it

Implementing MTA-STS requires two things: 1. A DNS TXT record at _mta-sts.yourdomain.com: v=STSv1; id=20240101001 2. A policy file hosted at: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt Policy file content: version: STSv1 mode: enforce mx: mail.yourdomain.com max_age: 86400 Start with mode: testing to see reports before enforcing. Use mta-sts.io for a guided setup.

What is this?

The WordPress version number is visible in the HTML source — either in the generator meta tag (<meta name="generator" content="WordPress 6.2">) or in script/style URLs as ?ver=6.2.

Why does it matter?

Knowing the exact WordPress version allows attackers to look up known CVEs (Common Vulnerabilities and Exposures) for that version and target known exploits. Version disclosure is an information leak that makes targeted attacks easier.

How to fix it

Remove the generator meta tag by adding to functions.php: remove_action('wp_head', 'wp_generator'); Remove ?ver= query strings from URLs: function remove_version_strings($src) { if (strpos($src, '?ver=') !== false) { $src = remove_query_arg('ver', $src); } return $src; } add_filter('style_loader_src', 'remove_version_strings'); add_filter('script_loader_src', 'remove_version_strings'); Alternatively use a security plugin like Wordfence or iThemes Security which does this automatically.

What is this?

The WordPress REST API exposes a /wp-json/wp/v2/users endpoint that by default lists all registered user accounts, including their usernames and display names.

Why does it matter?

Knowing valid usernames makes brute-force login attacks dramatically easier — an attacker no longer needs to guess both the username and password. They can enumerate all users in seconds and then focus password attacks on those known accounts.

How to fix it

Add to your theme's functions.php: add_filter('rest_endpoints', function($endpoints) { if (isset($endpoints['/wp/v2/users'])) { unset($endpoints['/wp/v2/users']); } if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) { unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']); } return $endpoints; }); Or use a security plugin like Wordfence or iThemes Security that includes this option.

What is this?

Subresource Integrity (SRI) is a browser security feature that lets you specify a cryptographic hash for external scripts and stylesheets. The browser refuses to execute the resource if its content does not match the hash.

Why does it matter?

If a CDN you rely on is compromised (a real and recurring attack vector), an attacker can replace your JavaScript library with malicious code that steals user data, injects cryptomining scripts, or performs other attacks. SRI prevents this by making the browser verify the file has not been altered.

How to fix it

Add integrity= and crossorigin= attributes to your external resources: <script src="https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js" integrity="sha256-/JqT3SQfawRcv/BIHPThkBvs0OEvtFFmqPF/lYI/Cxo=" crossorigin="anonymous" ></script> Generate hashes for any URL at: https://www.srihash.org/ For build tools, use webpack-subresource-integrity or vite-plugin-sri to add hashes automatically during builds.

What is this?

Permissions-Policy (formerly Feature-Policy) lets you control which browser features and APIs your site is allowed to use, and whether third-party content embedded in iframes can access them.

Why does it matter?

Without this header, embedded third-party scripts or iframes could theoretically request access to the camera, microphone, geolocation, payment APIs, and more. Restricting these features reduces your attack surface.

How to fix it

Example header that disables features not needed for most sites: Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=() Nginx: add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always; Apache: Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()" Only disable features you genuinely don't use. Adding this header is a low-effort, high-value improvement.

What is this?

Time To First Byte (TTFB) is the time between the browser sending a request and receiving the first byte of the response from the server. It reflects server processing time, not download speed.

Why does it matter?

A slow TTFB means the server takes too long to process each request — caused by slow database queries, no caching, or underpowered hosting. Google uses TTFB as a signal in Core Web Vitals. Pages with high TTFB feel slow even on fast connections.

How to fix it

Common fixes depending on the cause: 1. Enable server-side caching - WordPress: WP Super Cache, W3 Total Cache - Laravel: Response caching, OPcache - Nginx: FastCGI cache 2. Add a CDN (Content Delivery Network) - Cloudflare (free tier available) - Serves cached responses from edge servers close to the visitor 3. Optimise slow database queries - Enable query logging and identify N+1 problems - Add database indexes 4. Upgrade hosting - Shared hosting often has high TTFB under load - Consider a VPS or managed hosting like Laravel Forge + DigitalOcean Note: our measurement is taken from our server. Geographic distance adds latency — use a CDN to reduce this globally.