Free Email and Application Security practice questions

BIMI publishes a logo that supporting mail clients show beside authenticated messages, and it requires DMARC at enforcement, meaning quarantine or reject for all mail; p=none never qualifies. DKIM selector records hold public keys and SPF includes authorize sending servers, so neither carries a logo.

p=none is a monitoring setting: receivers deliver failing mail normally and only send reports, so spoofed mail keeps arriving. With every legitimate sender already passing with alignment, the next step is quarantine and then reject. Strict alignment, a new DKIM key and BIMI change nothing while the policy still tells receivers to deliver failing mail.

SPF breaks on forwarding because the forwarding server's IP address isn't on the original domain's list, but a DKIM signature travels inside the message and survives ordinary forwarding, and one aligned pass is enough for DMARC. A softfail is still not an SPF pass, strict SPF alignment only tightens how the SPF domain must match the From domain and can't rescue a failed SPF check, and BIMI displays a logo without authenticating anything.

A domain that never sends mail should say so: v=spf1 -all authorizes no servers, and DMARC at p=reject tells receivers to refuse anything claiming to come from it. Domains without records get spoofed because nobody is watching, +all authorizes the whole internet, and a DKIM key or BIMI record does nothing for a domain that sends no mail.

The Authentication-Results header her own receiving server added records the checks that server performed. Headers further down came from earlier hops, and a sender can forge those, including one claiming to come from the sender's own outbound server, so a pass in a lower header proves nothing.

SameSite limits sending the cookie on cross-site requests, which reduces cross-site request forgery; Strict never sends it on requests that start elsewhere. HttpOnly stops scripts from reading the cookie, Secure keeps it off plaintext HTTP, and Max-Age only sets how long it lives.

The Secure attribute tells the browser to send the cookie only over HTTPS, so it never travels in a plaintext request that someone on the same network can capture. HttpOnly only stops scripts from reading the cookie, SameSite governs requests that start from other sites, and a shorter lifetime still exposes the token on any HTTP request it rides on.

When legitimate data must contain characters such as < and >, validation can't reject them without breaking the application, so the protection has to happen at output: encoding < as &lt; makes the browser display the text instead of running it. HttpOnly stops a script from reading the cookie but not from acting in the page as the agent, and a check in the browser runs where the attacker can skip it.

Dynamic analysis attacks a running copy of the application from outside, doesn't need source code, and finds runtime and configuration flaws such as missing headers and cookies without attributes. Static analysis reads source code or binaries and can't see the deployed environment, while code signing and input validation are controls to apply, not ways to test.

A timestamp authority countersigns the signature with the time it was made, proving the code was signed while the certificate was valid, so the signature stays valid after the certificate expires. Hardware storage protects the key from theft, and a published hash or an HTTPS download speaks to the file and the connection; none of them keeps an old signature valid past expiry.