Selenium Security & Authentication 2 — Questions and Answers
Question 1: When testing OAuth 2.0 flows with Selenium, what is the recommended approach for handling the authorization code exchange?
- Automate the full browser redirect flow each time
- Use a pre-obtained access token injected via API to skip the browser UI (Correct answer)
- Store credentials in a shared test fixture file
- Disable OAuth and use basic auth in test environments
Correct answer: Use a pre-obtained access token injected via API to skip the browser UI
Injecting a pre-obtained token via API bypasses flaky redirect flows and keeps tests focused on application behavior rather than the auth provider.
Question 2: A Selenium test must verify that a page sets the HttpOnly flag on session cookies. Which approach correctly inspects this?
- Read document.cookie in JavaScript and check for HttpOnly
- Use driver.manage().getCookieNamed() and inspect the isHttpOnly property (Correct answer)
- Intercept the Set-Cookie response header via a browser proxy
- HttpOnly cookies cannot be tested with Selenium
Correct answer: Use driver.manage().getCookieNamed() and inspect the isHttpOnly property
WebDriver's Cookie object exposes isHttpOnly(), allowing direct programmatic assertion without needing a proxy.
Question 3: What does the SameSite=Strict cookie attribute mean, and how would you verify it in a Selenium test?
- Cookie is sent on all cross-site requests; verify via JS
- Cookie is never sent on cross-site requests; verify using driver.manage().getCookieNamed() and check sameSite property (Correct answer)
- Cookie is encrypted; verify by decoding the value
- Cookie expires after one session; verify by restarting the browser
Correct answer: Cookie is never sent on cross-site requests; verify using driver.manage().getCookieNamed() and check sameSite property
SameSite=Strict prevents the cookie from being sent on any cross-origin request, and Selenium's Cookie object includes the sameSite attribute.
Question 4: While automating a login page, your Selenium test encounters a CAPTCHA. What is the best practice for handling it in CI pipelines?
- Use an OCR library to solve CAPTCHAs automatically
- Whitelist the test environment IP or use a CAPTCHA bypass token provided by the dev team (Correct answer)
- Hardcode the CAPTCHA solution in the test
- Skip authentication tests entirely in CI
Correct answer: Whitelist the test environment IP or use a CAPTCHA bypass token provided by the dev team
Whitelisting test IPs or using bypass tokens is the sanctioned approach that avoids circumventing security controls inappropriately.
Question 5: Which Selenium capability allows you to configure a browser to trust a self-signed certificate during security testing?
- driver.get() with an https:// URL automatically trusts all certificates
- Setting acceptInsecureCerts to true in DesiredCapabilities or browser Options (Correct answer)
- Using InsecureRequestWarnings suppression in the test runner
- Launching the browser with --headless flag
Correct answer: Setting acceptInsecureCerts to true in DesiredCapabilities or browser Options
acceptInsecureCerts: true in the browser options instructs WebDriver to bypass certificate validation errors for self-signed certs.
Question 6: How can Selenium be combined with OWASP ZAP to perform automated security scanning during a test run?
- Configure Selenium to use ZAP as an HTTP proxy so all traffic is passively scanned (Correct answer)
- Run ZAP independently after Selenium finishes and compare logs
- Use ZAP's built-in WebDriver replacement instead of Selenium
- Install ZAP as a browser extension and launch it via addExtensions()
Correct answer: Configure Selenium to use ZAP as an HTTP proxy so all traffic is passively scanned
Routing Selenium browser traffic through ZAP as a proxy allows passive and active scanning of every request and response during the automated test.
Question 7: What is the risk of storing test credentials in plain text inside a Selenium test file committed to version control?
- It slows down test execution due to file size
- Credentials can be exposed publicly, enabling unauthorized access to test or production systems (Correct answer)
- Selenium cannot read plain text files for credentials
- It causes WebDriver session timeouts
Correct answer: Credentials can be exposed publicly, enabling unauthorized access to test or production systems
Plain-text credentials in source control can be leaked via repository access, history exposure, or accidental public repo pushes.
Selenium Security & Authentication 2
When testing OAuth 2.0 flows with Selenium, what is the recommended approach for handling the authorization code exchange?