Preventing JavaScript Injection on Web Servers
Short answer
AD Prevent JavaScript injection on the web servers by keeping server software patched and deploying a web-application firewall to filter malicious requests.
Question
Key Takeaways
It tests prevention controls for web-application injection, and the trap is selecting detection or impact-reduction measures such as vulnerability scans or data removal instead of controls that stop the malicious request.
This SY0-701 scenario tests how to prevent malicious JavaScript injection against web servers that handle payment data. The correct controls are regular server patching (A) and a web-application firewall (D), because both directly block the injection path.
Common mistake: A common wrong choice is E, regular vulnerability scans, because scanning finds injection flaws but does not block an exploit; similarly, F reduces stolen-data impact but does not prevent the web-server attack.
Expert Analysis
Prevention versus detection or impact reduction The stem asks which strategies prevent a JavaScript injection attack against the web servers. CompTIA-style scenarios reward controls that directly stop the exploit path. JavaScript injection, including cross-site scripting and script injection, succeeds when an application handles untrusted input insecurely; the strongest options either remove exploitable code or filter malicious HTTP requests before they reach the application. Options A and D fit that prevention role.
Why A is correct Regularly updating server software and patches removes known flaws in the web server, frameworks, libraries, and runtime components that injection attacks can exploit. Patch management is preventive because it eliminates the vulnerable code path before an attacker can use it, rather than discovering the issue afterward.
Why D is correct A web-application firewall inspects HTTP/HTTPS traffic and can block request payloads and patterns associated with script injection. It provides input filtering and virtual patching in front of the web server, directly interrupting malicious requests.
Why the other options miss the requirement B, strong password policies, addresses credential attacks, not injection. C, encrypting data at rest and in transit, protects confidentiality if data is exposed but does not stop script execution or request manipulation. E, regular vulnerability scans, identifies weaknesses for remediation; it is an assessment control, not a blocking control. F, removing payment information from the servers, is excellent data minimization and reduces PCI scope and breach impact, but it does not prevent an attack on the web servers. Some discussion favors scans or cardholder-data removal, but those address discovery or impact rather than attack prevention. The decisive pair is A and D.
Official Reference
- https://www.comptia.org/certifications/security
- https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
- https://owasp.org/www-project-modsecurity-core-rule-set/
These links open the official vendor documentation in a new tab.
Exam Strategy
In multi-select SY0-701 scenarios, underline the verb in the stem: prevent, detect, or reduce impact. Here, "preventing an attack" means choosing controls that directly interrupt the exploit: patching removes vulnerable code, and a WAF filters malicious requests. Reject options that only find weaknesses, protect stored data, or strengthen credentials unless the stem asks for those outcomes. Verify exactly two selections when the question demands two.
Frequently Asked Questions
Why isn't a vulnerability scan the best prevention control for JavaScript injection?
Does encrypting payment data prevent a JavaScript injection attack?
Why not remove payment information from the servers instead?
Community Votes
50% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 6 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 6
-
Fourgehan 👍 8A. Regularly updating server software and patches (Keeping server software and any associated components up to date is essential in preventing known vulnerabilities from being exploited. This includes updating the web server, libraries, frameworks, and other software that could be vulnerable to attack, including JavaScript injection vulnerabilities) D. Utilizing a web-application firewall (A WAF is specifically designed to filter, monitor, and block malicious traffic directed at a web application. It can detect and block a wide range of attacks, including JavaScript injection, cross-site scripting (XSS), and other common web-based threats)
-
AriGarcia 👍 2Keeping server software up-to-date ensures that known vulnerabilities, including those that could be exploited for JavaScript injection, are patched. Many attacks exploit outdated software, so this is a critical step in mitigation. A WAF is specifically designed to detect and block malicious web traffic, including JavaScript injection attacks. It inspects incoming HTTP/S requests and can filter out malicious payloads targeting vulnerabilities in web applications.
-
9149f41 👍 2The question is to protect the web server only from JavaScript injection. Strong passwords, data encryption, and vulnerability checks cannot protect javascript injection. Only update and patch the web server, and WAF can protect JavaScript, in fact, from any injection attack.
-
ProudFather 👍 1A web application firewall (WAF) is specifically designed to protect web applications from attacks like SQL injection, cross-site scripting (XSS), and other web-based vulnerabilities. It can filter and block malicious requests, preventing attackers from exploiting vulnerabilities in the web application. Regular vulnerability scans help identify and address vulnerabilities in the web servers and applications. This includes identifying and patching the vulnerability that allowed the JavaScript injection.
-
Dumbledores_Army 👍 1D. Utilizing a web-application firewall (WAF) F. Removing payment information from the servers — This follows PCI DSS best practices and reduces risk by not storing cardholder data (e.g., PAN, CVV) on the organization's servers at all. Use tokenization (replace sensitive data with tokens) or redirect to a PCI-compliant third-party processor
Show 1 more comment
-
pourus 👍 1As per the question, you need to prevent an attack on the web server. Option F does not help with that. A & D are correct.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All SY0-701 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SY0-701 Practice Test →