Internet, Web and Application Security

Introduction and Context

Internet-facing systems provide essential services but operate in an environment where an attacker may be anonymous, geographically distant, automated, and able to probe continuously. A public website, DNS service, application programming interface (API), cloud workload, or email gateway can therefore become an entry point into an organisation’s information systems.

Internet, web, and application security is concerned with protecting communication, identity, sessions, data, software components, and service availability. It combines network controls such as firewalls and intrusion prevention with secure protocols, defensive software engineering, identity management, monitoring, and incident response.

The central security objectives remain confidentiality, integrity, and availability (the CIA triad), supplemented by authenticity, accountability, privacy, and non-repudiation. These objectives are interdependent. For example, encryption may preserve confidentiality but cannot by itself prevent a compromised application from authorising an attacker to access another user’s records.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain common internet-facing threats, including spoofing, session attacks, DNS abuse, denial-of-service attacks, and malware.
2. Describe how HTTP, TLS, DNS security mechanisms, and related protocols support secure communication.
3. Identify common web vulnerabilities using the OWASP risk perspective.
4. Apply defensive controls for input validation, authentication, authorisation, session management, APIs, and secure configuration.
5. Analyse a realistic application-security incident and recommend proportionate responses.
6. Discuss governance, privacy, ethical, and operational considerations in internet security.

1. The Internet-Facing Attack Surface

An attack surface is the collection of interfaces through which a system can be reached or influenced. It includes visible elements such as web pages and APIs, as well as less obvious components such as DNS records, cloud storage, administrative portals, third-party scripts, software dependencies, certificates, and forgotten subdomains.

A useful distinction is between exposure, vulnerability, and risk:

• Exposure means that a service or asset is reachable or discoverable.
• A vulnerability is a weakness that can be exploited.
• Risk combines the likelihood and impact of an adverse event, while recognising that precise numerical estimates are often uncertain.

Internet-facing risk is amplified by automation. Attackers can scan thousands of hosts, test common passwords, replay stolen tokens, and deploy malware at a scale that manual defenders cannot match. Security therefore requires secure defaults, layered controls, continuous monitoring, and rapid patching rather than reliance on a single perimeter device.

Trust Boundaries

A trust boundary is a point where data, identity, or authority crosses from one security context to another. Typical boundaries include:

• a browser communicating with a web server;
• an application communicating with a database;
• an API gateway forwarding a request to a microservice;
• a cloud workload receiving traffic from the public internet; and
• an organisation accepting data from a partner.

Every boundary should have explicit assumptions. A web application must not assume that a request came from its own user interface, because an attacker can construct requests directly. Similarly, a service must not trust a value merely because it was supplied by another internal service unless the service identity and message integrity are verified.

2. Spoofing, Identity and Trust Abuse

Spoofing occurs when an attacker presents false identity or origin information. Examples include IP spoofing, email spoofing, DNS spoofing, website impersonation, and forged authentication tokens.

IP spoofing changes the apparent source address of packets. It can support reflection attacks and confuse poorly designed access controls, although a spoofed source generally cannot complete a normal two-way TCP session because replies return to the legitimate address. Defences include ingress and egress filtering, stateful firewalls, and application-layer authentication.

Email spoofing exploits weaknesses in the interpretation of message origin. Sender Policy Framework (SPF) allows a domain to publish authorised sending hosts. DomainKeys Identified Mail (DKIM) adds a cryptographic signature to message content and selected headers. Domain-based Message Authentication, Reporting, and Conformance (DMARC) enables a domain owner to specify how receivers should handle messages that fail SPF or DKIM alignment and to receive reports. These mechanisms reduce, but do not eliminate, phishing: a compromised legitimate account can send validly authenticated messages.

Website spoofing and phishing commonly use look-alike domains, cloned interfaces, misleading links, or compromised advertising networks. Users and organisations should verify the complete domain, use phishing-resistant multifactor authentication where possible, apply email filtering, and avoid treating the presence of HTTPS as proof that a site is trustworthy. HTTPS authenticates the server identified by its certificate; it does not guarantee that the site is honest.

3. Secure Internet Protocols

HTTP and HTTPS

HTTP is an application protocol for transferring requests and responses. In plain HTTP, content can be observed or modified by an attacker able to intercept traffic. HTTPS is HTTP carried through Transport Layer Security (TLS). TLS provides:

1. confidentiality through encryption;
2. integrity through authenticated protection of records; and
3. server authentication through certificates issued within a trusted public-key infrastructure.

A simplified TLS interaction includes negotiation of protocol parameters, certificate validation, key agreement, and establishment of symmetric session keys. Modern deployments should use current TLS versions, strong cipher suites, valid certificates, secure private-key storage, and correct certificate-chain configuration. TLS does not protect data after it reaches a compromised server, and it does not replace authorisation controls.

HTTP security headers can reduce browser-side risk. Important examples include:

• Strict-Transport-Security (HSTS): instructs a browser to use HTTPS for a domain for a specified period.
• Content-Security-Policy (CSP): restricts permitted script, style, image, and connection sources.
• X-Content-Type-Options: reduces MIME-type confusion by instructing browsers not to sniff content types.
• Referrer-Policy: limits information transmitted in the referrer header.
• Permissions-Policy: restricts browser features such as camera or microphone access.

Headers must be tested because an incorrect policy can break legitimate functionality or create a false sense of security.

Secure Name Resolution

The Domain Name System (DNS) maps names to records such as IP addresses and mail servers. Traditional DNS does not inherently authenticate responses, allowing cache poisoning or manipulation by an attacker who can interfere with resolution.

DNS Security Extensions (DNSSEC) use digital signatures to provide origin authentication and integrity for signed DNS data. DNSSEC does not encrypt ordinary DNS queries and does not conceal which names are requested. DNS over HTTPS (DoH) and DNS over TLS (DoT) protect the client-to-resolver channel from local observation or manipulation, but they do not, by themselves, prove that every returned record is correct. DNSSEC and encrypted transport address different threats and may be used together.

Operational DNS controls include registrar account protection, multi-person approval for sensitive changes, registry lock where available, monitoring for unauthorised record changes, short but sensible TTL planning, and removal of abandoned subdomains.

4. Sessions, Cookies and Authentication Attacks

HTTP is stateless: each request is independent unless an application associates requests with a session. A session identifier is commonly stored in a cookie or sent in an authorisation header. Possession of a valid session token may be equivalent to possession of the user’s authenticated session, so tokens must be protected like passwords.

Common Session Attacks

• Session hijacking: an attacker obtains a valid token through malware, traffic interception, browser compromise, logging, or a vulnerable application.
• Session fixation: an attacker causes a victim to authenticate using a session identifier known to the attacker.
• Cross-site request forgery (CSRF): a victim’s browser is induced to send an unwanted state-changing request while automatically including authentication credentials.
• Token replay: a captured token is reused before it expires or is revoked.

Defensive practices include using HTTPS for the entire session, regenerating the session identifier after login and privilege changes, setting cookies with Secure, HttpOnly, and appropriate SameSite attributes, enforcing idle and absolute timeouts, providing server-side revocation, and avoiding sensitive information in URLs. CSRF tokens, SameSite cookies, origin checking, and re-authentication for high-risk actions provide complementary protection.

A secure session design should also detect unusual behaviour such as impossible geographic movement, simultaneous use from inconsistent devices, excessive token failures, or sudden privilege changes. Detection must be balanced against privacy and the risk of locking out legitimate users.

Authentication and Authorisation

Authentication answers “Who are you?” Authorisation answers “What may you do?” Confusing these functions causes serious vulnerabilities. A user may be correctly authenticated yet authorised to access only their own records.

Passwords should be stored using a slow, memory-hard password hashing function with a unique salt, not through reversible encryption or a fast general-purpose hash. Multifactor authentication reduces the effect of password theft. Phishing-resistant methods, such as hardware-backed passkeys using public-key credentials, are stronger than one-time codes sent by email or SMS, although deployment and recovery processes require careful design.

Authorisation should be enforced on the server for every sensitive operation. The principle of least privilege grants only the permissions required for a task. Deny-by-default policies, centralised policy decisions, object-level access checks, and tests for horizontal and vertical privilege escalation are essential.

5. Denial of Service and Availability

A denial-of-service (DoS) attack attempts to make a system or service unavailable. A distributed denial-of-service (DDoS) attack uses many sources, commonly compromised devices or reflection/amplification services.

Attacks may target different layers:

• volumetric attacks consume network bandwidth;
• protocol attacks exhaust connection or state-tracking resources; and
• application-layer attacks consume CPU, memory, database connections, or expensive business logic.

A useful capacity relationship is:

where R_required is the capacity required to serve traffic, R_legitimate is legitimate demand, and R_attack is attack traffic or attack-induced work. This is a planning relationship, not a guarantee of availability: bottlenecks may occur in bandwidth, load balancers, connection tables, application threads, databases, or third-party dependencies.

Defences include upstream DDoS scrubbing, content delivery networks, anycast distribution, rate limiting, request quotas, caching, autoscaling with spending controls, connection limits, circuit breakers, graceful degradation, resilient DNS, and a tested incident runbook. Rate limits should distinguish unauthenticated clients, accounts, IP ranges, and expensive operations; an IP-only limit can unfairly affect users behind shared networks.

Availability engineering must address legitimate surges as well as attacks. Load tests should identify bottlenecks, and recovery objectives should be documented. A control that improves availability but automatically scales without a budget limit can create a costly secondary failure.

6. Malware and Malicious Content

Malware includes viruses, worms, trojans, ransomware, spyware, botnet agents, rootkits, and malicious scripts. Internet-facing applications encounter malware through uploads, compromised dependencies, drive-by downloads, malicious advertisements, infected endpoints, and supply-chain compromise.

A secure file-upload design should:

1. allow only required file types and sizes;
2. validate file content rather than trusting extensions or client-supplied MIME types;
3. rename files and store them outside executable web directories;
4. scan files using updated malware detection where appropriate;
5. remove active content when business requirements permit;
6. isolate processing in a sandbox or separate service; and
7. apply least privilege to storage and processing accounts.

Malware detection is imperfect. Behavioural monitoring, application allow-listing, endpoint detection and response, backups protected from ransomware, patch management, and user awareness provide additional layers. Backups must be tested through restoration exercises; an untested backup is an assumption, not a recovery capability.

Software supply-chain security includes dependency inventories, version pinning where practical, signed releases, vulnerability monitoring, protected build pipelines, separation of build and production credentials, and review of third-party scripts. A dependency that is technically trusted may still introduce privacy, availability, or licensing risk.

7. Common Web Vulnerabilities and OWASP-Aligned Defences

The OWASP Top 10 is an awareness and risk-communication resource, not a complete security standard. It highlights recurring categories such as broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, identification and authentication failures, software and data integrity failures, security logging and monitoring failures, and server-side request forgery (SSRF). Organisations should adapt the categories to their own threat models.

Injection

Injection occurs when untrusted data is interpreted as code or commands. SQL injection can result when an application constructs database queries by concatenating user input. The primary defence is parameterised queries or prepared statements. Input validation, least-privileged database accounts, safe stored procedures, and generic error messages provide additional protection. Escaping alone is context-dependent and should not be the primary defence.

Other forms include operating-system command injection, LDAP injection, template injection, and expression-language injection. Each interpreter requires context-specific controls.

Cross-Site Scripting

Cross-site scripting (XSS) occurs when attacker-controlled content executes in another user’s browser. Reflected XSS is returned immediately in a response; stored XSS persists in server-side data; DOM-based XSS arises from unsafe client-side processing.

Defences include context-appropriate output encoding, safe templating frameworks, input constraints, sanitisation for permitted rich text, CSP, and secure cookie attributes. Encoding must match the output context: HTML, attribute, JavaScript, CSS, and URL contexts differ.

Broken Access Control and IDOR

Insecure direct object reference (IDOR) occurs when a user changes an identifier, such as /invoice/1001 to /invoice/1002, and receives another user’s object. Unpredictable identifiers may reduce enumeration but do not replace authorisation checks. The server must verify that the authenticated principal has permission to access the requested object and action.

Security Misconfiguration

Examples include default passwords, verbose production errors, exposed administrative interfaces, unnecessary HTTP methods, public cloud storage, debug mode, permissive CORS policies, and missing security headers. Secure configuration should be automated, documented, version-controlled, and continuously checked for drift.

SSRF

Server-side request forgery occurs when an application fetches a URL supplied by a user and can be induced to reach internal services, cloud metadata endpoints, or restricted systems. Defences include strict allow-lists, URL parsing that resists alternate representations, blocking private and link-local ranges, controlling redirects, egress filtering, network segmentation, and protecting cloud metadata services. DNS rebinding and time-of-check/time-of-use changes mean that validation should be designed carefully and performed throughout the request process.

Cryptographic Failures

Sensitive data should be classified before selecting protection. Use modern, maintained cryptographic libraries; protect keys separately from encrypted data; avoid custom cryptography; and define rotation, revocation, and recovery procedures. Encryption in transit does not remove the need for access control, and encryption at rest does not prevent an authorised but compromised application from reading plaintext.

8. API Security

APIs expose functions and data to browsers, mobile applications, partners, and internal services. Their security must be designed independently of the user interface because an attacker can call an API directly.

Core API controls include:

• strong authentication and narrowly scoped tokens;
• object-level, function-level, and property-level authorisation;
• schema validation and strict content types;
• rate limits, quotas, and pagination limits;
• protection against replay and excessive data exposure;
• secure error handling and consistent audit logs;
• version management and retirement of obsolete endpoints;
• validation of webhooks and partner callbacks; and
• monitoring for unusual call sequences and data extraction.

OAuth 2.0 is an authorisation framework, not a complete identity protocol. OpenID Connect adds an identity layer. Tokens should have limited audience, scope, lifetime, and issuer validation. A service should not accept a token merely because it is syntactically valid. It should verify signature, issuer, audience, expiry, intended use, and required scope.

API gateways can centralise authentication, throttling, routing, and logging, but business authorisation must still be enforced by the service that owns the resource. Gateway-only controls may be bypassed by internal paths or misconfigured routes.

9. Secure Development and Verification

Application security is most effective when integrated into the software development life cycle. A practical secure development process includes:

1. Requirements and threat modelling: identify assets, actors, trust boundaries, abuse cases, and security requirements.
2. Secure design: choose least privilege, safe defaults, resilient architecture, and appropriate cryptography.
3. Implementation: use approved libraries, code review, parameterised queries, and secure error handling.
4. Verification: perform static analysis, dependency scanning, dynamic testing, manual review, and targeted penetration testing.
5. Release: use protected pipelines, approvals, signed artefacts, and configuration checks.
6. Operation: monitor, patch, rotate secrets, respond to incidents, and learn from defects.

Automated tools are valuable but incomplete. Static analysis may produce false positives and miss business-logic flaws. Dynamic scanners may not understand authorisation rules. Penetration tests provide useful evidence but represent a point in time. Security tests should therefore include unit tests for access control, integration tests for authentication flows, abuse-case tests, and regression tests for previously discovered vulnerabilities.

10. Logging, Detection and Incident Response

Security logging should support detection, investigation, and accountability. Useful events include authentication successes and failures, token issuance and revocation, privilege changes, administrative actions, access-denied events, suspicious input patterns, rate-limit triggers, configuration changes, and data exports.

Logs should contain reliable timestamps, request or correlation identifiers, service identity, outcome, and enough context to investigate without unnecessarily recording sensitive data. Passwords, session tokens, full payment-card data, and private health information should not be logged. Logs require access control, integrity protection, retention rules, and monitoring.

A basic incident process consists of preparation, detection and analysis, containment, eradication, recovery, and lessons learned. Internet incidents may require certificate revocation, DNS changes, token invalidation, emergency rate limiting, customer notification, evidence preservation, and coordination with providers or regulators. Decisions should be documented because availability pressure can otherwise lead to uncontrolled changes that destroy evidence or create further exposure.

11. Illustrative Case: The Exposed Booking API

Background

A fictional travel company, Northstar Travel, provides a public booking application and mobile API. Customers authenticate using email and password, and bookings are identified by sequential numeric values.

Problem

A customer reports seeing another customer’s itinerary after changing the booking number in a mobile API request. Monitoring also shows repeated requests for thousands of booking identifiers. The application logs contain request paths but not authenticated user identifiers or authorisation decisions.

Analysis

The immediate issue is broken object-level authorisation, often described as IDOR. The sequential identifier makes enumeration easy, but replacing identifiers with random values would not solve the underlying problem. The absence of useful logs delays determination of how many records were accessed. The incident may also involve personal-data exposure, creating legal and notification considerations.

Approach and Solution

Northstar first disables the affected endpoint and routes customers to a safer booking lookup flow. It preserves relevant logs, identifies accessed records, and invalidates suspicious tokens. Engineers implement a server-side ownership check for every booking operation and add tests for horizontal privilege escalation. They introduce correlation identifiers, authenticated principal logging with privacy controls, and alerts for high-volume denied access.

The organisation then reviews all API endpoints, applies a documented authorisation policy, limits enumeration through quotas and pagination controls, and conducts a privacy impact assessment. Customers and regulators are notified where required by applicable law. A follow-up review identifies similar risks in invoices and loyalty records.

Outcome

The immediate vulnerability is removed, unauthorised access is investigated, and the development process is changed so that object-level authorisation tests are required before release. The company also separates public identifiers from internal database keys, while recognising that this is a defence-in-depth measure rather than the main control.

Learning Points

1. Authentication does not imply authorisation.
2. Client interfaces cannot be trusted to enforce access restrictions.
3. Secure logging is essential for determining impact.
4. API security must include business-logic and object-level tests.
5. Privacy, incident response, and engineering decisions are connected.

12. Governance, Ethics and Contemporary Developments

Security practitioners must balance protection with legitimate access, privacy, accessibility, and proportionality. Collection of detailed behavioural telemetry may improve fraud detection but can create surveillance and data-protection risks. Organisations should define purpose, minimise collection, restrict access, retain data only as necessary, and communicate material practices transparently.

Legal duties vary by jurisdiction and sector, but may include breach notification, protection of personal data, payment-card requirements, critical-infrastructure obligations, and records of processing. Compliance does not equal security: an organisation may satisfy a checklist while retaining exploitable design flaws.

Artificial intelligence is increasingly used for anomaly detection, code assistance, phishing generation, and automated attack discovery. AI-generated code and security recommendations require human review because models can reproduce vulnerable patterns, mishandle secrets, or misunderstand business authorisation. Defensive AI systems should be evaluated for false positives, bias, data leakage, adversarial manipulation, and explainability. Sensitive code and logs should not be submitted to external services without appropriate approval and contractual safeguards.

Contemporary security practice is moving toward zero-trust principles, phishing-resistant authentication, software bills of materials, memory-safe programming for suitable components, continuous exposure management, confidential computing, and stronger supply-chain provenance. These developments complement rather than replace foundational practices such as patching, least privilege, secure design, and tested recovery.

13. Practical Security Checklist

For an internet-facing web or API service, a diploma-level review should ask:

• Are all external communications protected with correctly configured TLS?
• Are DNS records, registrar accounts, and certificates monitored?
• Are authentication, session management, and token revocation designed explicitly?
• Is authorisation checked on every sensitive server-side operation?
• Are inputs validated and interpreted safely in their context?
• Are uploads isolated, scanned, and prevented from executing?
• Are dependencies, secrets, cloud settings, and administrative interfaces controlled?
• Are rate limits, DDoS measures, caching, and graceful degradation tested?
• Are security-relevant events logged without exposing sensitive data?
• Are alerts connected to an incident-response plan and restoration-tested backups?
• Are privacy, regulatory, accessibility, and ethical impacts considered?

Chapter Summary

Internet, web, and application security protects systems that operate across untrusted networks and complex trust boundaries. Spoofing attacks undermine confidence in identity and origin; secure authentication, domain controls, and cryptographic protocols reduce this risk. TLS protects communication, while DNSSEC and encrypted DNS address different aspects of name-resolution security.

Session tokens require protection through secure transport, cookie attributes, regeneration, expiry, and revocation. Authentication must be separated from authorisation, and every object and function must be checked server-side. DoS and DDoS resilience requires capacity planning, upstream controls, rate limiting, caching, monitoring, and tested recovery. Malware defence depends on isolation, endpoint controls, secure uploads, dependency management, and reliable backups.

OWASP-aligned practice focuses attention on injection, XSS, broken access control, cryptographic failures, misconfiguration, vulnerable components, SSRF, and other recurring weaknesses. APIs require scoped tokens, schema validation, quotas, replay protection, and object-level authorisation. Secure development, logging, incident response, privacy governance, and human oversight of AI complete a defence-in-depth approach.

Key Terms

Attack surface: The collection of interfaces through which a system can be reached or influenced.

Authorisation: The process of determining what an authenticated identity is permitted to do.

CSRF: An attack that causes a victim’s browser to submit an unwanted request using existing credentials.

CSP: A browser security policy that restricts permitted content and script sources.

DDoS: A distributed denial-of-service attack using many sources to impair availability.

DNSSEC: DNS extensions that provide origin authentication and integrity for signed DNS data.

IDOR: Unauthorised access to an object by manipulating an identifier or reference.

Injection: The interpretation of untrusted data as commands or code.

Least privilege: Granting only the permissions required for an activity.

Malware: Software designed to perform unauthorised or harmful actions.

OAuth 2.0: A framework for delegated authorisation.

Phishing: Deceptive activity intended to obtain credentials, information, or harmful actions.

Rate limiting: Restricting the frequency or volume of requests.

Session hijacking: Use of another person’s valid session token.

Spoofing: Falsifying identity, origin, or source information.

SSRF: Causing a server to make unintended requests to another location.

TLS: A protocol providing authenticated, confidential, and integrity-protected communication.

Trust boundary: A point where data, authority, or identity crosses security contexts.

XSS: Injection of attacker-controlled script or active content into a user’s browser context.

Review Questions

Short Answer Questions

1. Distinguish exposure, vulnerability, and risk.
2. What security properties does TLS provide, and what does it not guarantee?
3. Why is authentication insufficient to prevent IDOR vulnerabilities?
4. Name three secure cookie attributes or session-management practices.
5. Explain the difference between DNSSEC and DNS over HTTPS.

Long Answer Questions

1. Explain the principal stages of a secure software development life cycle and describe the value of threat modelling.
2. Compare volumetric, protocol, and application-layer denial-of-service attacks and discuss suitable controls for each.
3. Discuss injection, XSS, broken access control, and SSRF, including a primary defence for each.
4. Design a secure API architecture for a mobile application, covering authentication, authorisation, validation, rate limiting, logging, and versioning.
5. Explain how privacy, regulatory duties, and ethical considerations influence incident response and security monitoring.

Analytical / Application Questions

1. An API accepts a customer ID from a mobile client and returns account details. A user can alter the ID and view another customer’s data. Analyse the vulnerability, identify immediate containment actions, and propose long-term controls.
2. A public service experiences slow responses during a traffic surge. Network bandwidth is available, but database connections are exhausted by expensive search requests. Determine which class of availability problem is most likely and recommend layered mitigations.
3. A company receives phishing emails from its own domain after an employee account is compromised. Analyse which email-authentication controls may still pass, recommend technical and procedural responses, and explain why domain authentication alone cannot eliminate phishing.

Multiple Choice Questions with Answers

Question 1

Which control most directly prevents an IDOR vulnerability?

A. Changing numeric identifiers to longer random values

B. Checking server-side whether the authenticated user may access the requested object

C. Adding a website privacy notice

D. Increasing the session timeout

Correct Answer: B. Checking server-side whether the authenticated user may access the requested object

Question 2

What is the primary purpose of TLS in HTTPS?

A. To guarantee that the website owner is honest

B. To provide confidentiality, integrity, and server authentication for communication

C. To replace application authorisation

D. To prevent all denial-of-service attacks

Correct Answer: B. To provide confidentiality, integrity, and server authentication for communication

Question 3

Which cookie attribute prevents client-side scripts from directly reading the cookie?

A. Secure

B. SameSite

C. HttpOnly

D. Path

Correct Answer: C. HttpOnly

Question 4

Which statement about DNSSEC is correct?

A. It encrypts all DNS queries by default

B. It provides signatures supporting DNS data integrity and origin authentication

C. It replaces the need to protect registrar accounts

D. It guarantees that a resolved website is free from malware

Correct Answer: B. It provides signatures supporting DNS data integrity and origin authentication

Question 5

What is the primary defence against SQL injection?

A. Parameterised queries or prepared statements

B. Hiding the database hostname

C. Increasing the web server timeout

D. Using sequential record identifiers

Correct Answer: A. Parameterised queries or prepared statements

Question 6

Which attack causes a server to make an unintended request to an internal service?

A. CSRF

B. SSRF

C. Session fixation

D. Credential stuffing

Correct Answer: B. SSRF

Question 7

Why should uploaded files be stored outside executable web directories?

A. To improve DNS resolution

B. To prevent an uploaded file from being directly executed as server-side code

C. To make files publicly searchable

D. To disable TLS inspection

Correct Answer: B. To prevent an uploaded file from being directly executed as server-side code

Question 8

Which API practice most directly limits the damage from a stolen access token?

A. Using unlimited token lifetime

B. Using narrowly scoped tokens with suitable expiry and validation

C. Placing the token in a URL

D. Disabling audit logging

Correct Answer: B. Using narrowly scoped tokens with suitable expiry and validation

Question 9

A service has sufficient bandwidth but its database connection pool is exhausted by expensive requests. Which control is most directly relevant?

A. Application-layer rate limiting and query-cost controls

B. Changing the organisation’s domain name

C. Disabling certificate validation

D. Publishing more DNS records

Correct Answer: A. Application-layer rate limiting and query-cost controls

Question 10

Which statement best describes DMARC?

A. It is a database encryption algorithm

B. It enables domain owners to specify handling and reporting for messages failing email-authentication alignment

C. It prevents all messages from compromised legitimate accounts

D. It is a replacement for multifactor authentication

Correct Answer: B. It enables domain owners to specify handling and reporting for messages failing email-authentication alignment