Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
System Security · Question Set
Web Sec interview questions for placements and exams.
Questions
15
Included in this set
Subject
System Security
Explore more sets
Difficulty
Mixed
Level of this set
Go through each question and its explanation. Use this set as a focused practice pack for System Security.
SSRF abuses a server’s ability to make HTTP calls. In cloud, attackers often target metadata services to steal credentials or pivot. Recent research shows active campaigns and rising prevalence; vendors recommend layered mitigations.
GET http://169.254.169.254/latest/meta-data/iam/security-credentials/
For complete preparation, combine this set with full subject-wise practice for System Security. You can also explore other subjects and sets from the links below.
Enforce ownership at every read and write. Do not rely on the client to hide IDs. Check object access with server-side lookups and role rules. Validate both object-level and property-level authorization so users cannot set privileged fields. Log deny decisions for audit. Add tests for IDOR and for mass-assignment paths. This aligns with OWASP API Top 10 guidance and reduces high-impact data leaks.
const obj = await repo.get(id); if (obj.owner !== auth.userId) return 403; const allowed = pick(body, editableFieldsFor(auth));
Generate strong, unpredictable tokens. Tie them to the user session. Send them in HTML or JSON, not in a cookie for synchronized token patterns. Validate on every state-changing request. Do not put tokens in URLs or logs. Rotate on login and at session renewal. For SPAs, fetch the token via a safe endpoint and attach it as a header. Keep SameSite on cookies for extra defense, but never rely on it alone
fetch('/csrf').then(t => localStorage.setItem('csrf', t))
// later: xhr.setRequestHeader('X-CSRF-Token', localStorage.getItem('csrf'))BOLA occurs when endpoints expose object identifiers without enforcing ownership checks, allowing unauthorized reads or edits. It remains the top API risk.
GET /api/users/1234 // must verify auth.userId == 1234 before returning
If the API blindly maps client fields to server models, attackers can set sensitive fields like isAdmin. OWASP’s API list merges this with property-level authorization concerns. Use explicit allowlists and server-side checks.
allowed = pick(req.body, ['name','email']); user.update(allowed);
CSP whitelists script sources and can block inline execution when designed well. It complements secure coding and output encoding to cut XSS risk.
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
Broken access control lets a user reach data or actions they should not. Common causes include missing server-side checks, IDOR issues, and deny-by-default not enforced. OWASP lists this as the top web risk and gives practical examples and fixes.
if (resource.ownerId !== auth.userId) return res.status(403).end();
Security misconfiguration includes unsafe defaults, extra features, verbose errors, open cloud storage, and missing patches. It is common and easy to fix with hardened baselines and automation.
spring.profiles.active=prod server.error.include-stacktrace=never
Anti-CSRF tokens are unique per session or request and validated by the server. They should not ride in URLs and should not be stored in cookies for synchronized patterns. SameSite adds defense in depth but is not enough alone.
POST /transfer Headers: X-CSRF-Token: abcd1234 Body: amount=500&to=42
SameSite limits when browsers send cookies on cross-site requests. It helps against CSRF and some cross-site leaks. It is a defense in depth and should be combined with tokens.
Set-Cookie: sid=...; Secure; HttpOnly; SameSite=Strict
APIs are easy to automate. Attackers exploit this for brute force, scraping, and credential stuffing. Rate limits slow abuse and protect upstream services. Apply limits per user, per IP, and per token. Include burst and sustained windows. Return clear errors and backoff hints. Combine with detection for anomalous patterns and block lists. Tie limits to critical operations, like login or password reset, for stronger protection.
POST /login 5 req per min per account; 100 req per min per IP; exponential backoff on 429
CORS does not block raw HTTP requests. It governs whether browser-run code can read the response. Configure explicit allowlists and avoid reflecting wildcard with credentials. This prevents unintended data exposure to other sites.
Access-Control-Allow-Origin: https://app.example.com Access-Control-Allow-Credentials: true
Parameterized queries send the SQL and the data separately. The driver never treats input as code, so injected quotes do not change the query plan. Use prepared statements by default. If you use an ORM, still validate fields and avoid dynamic string concatenation. For complex reports, stored procedures can help, but they must also use parameters. Add least-privilege DB accounts and monitor for unusual query patterns.
SELECT * FROM users WHERE email = ?; // driver binds value, not SQL
Clickjacking tricks a user into clicking a hidden frame. Deny framing or allow only trusted parents. Pair this with CSRF defenses on state-changing actions to limit damage.
X-Frame-Options: DENY Content-Security-Policy: frame-ancestors 'none'
Watch for egress calls to link-local and RFC-1918 ranges, odd DNS names, and unusual response sizes from metadata hosts. Add egress allowlists at app and network layers. Log request targets and block raw redirects. Use DNS and HTTP proxies with policies to prevent direct access to internal endpoints. In cloud, harden the metadata service and use instance profiles with the latest protections. Alerts on these signals help you stop credential theft and lateral movement early.
Alert if dest in 169.254.169.0/16 or 10.0.0.0/8 and Host header not in allowlist