Below I will be sharing some interview questions I came across.
But the answers of these may be correct or may not be. You have to check that once.
Plus the kind of answer will also depends on what your interviewer wants to hear or knows about.
So you are on your own there, if the interviewer doesn't know about your answer & s/he can reject you even though you are right.
Will really be helpful if you can also share your thoughts on this.
But the answers of these may be correct or may not be. You have to check that once.
Plus the kind of answer will also depends on what your interviewer wants to hear or knows about.
So you are on your own there, if the interviewer doesn't know about your answer & s/he can reject you even though you are right.
Will really be helpful if you can also share your thoughts on this.
Interview 1 : This question has been asked in a few interviews with Deutsche Bank, Xoriant,
Sapient like. How you will make your web service secure or how you include
security in your web service?
Answer : Like I say, it depends on what your interviewer knows the answer of this or want to
listen. But I think such questions are quiet abstract & the answers of these can
depend on many factors like what kind of security ?
Questions like this are quite broad, and the ideal answer depends on factors like the application context, the nature of the resources, and the architecture (monolithic vs. microservices). Here is a structured approach covering the essential dimensions of web service security:
A) Transport-Level Security (Data in Transit)
Sapient like. How you will make your web service secure or how you include
security in your web service?
Answer : Like I say, it depends on what your interviewer knows the answer of this or want to
listen. But I think such questions are quiet abstract & the answers of these can
depend on many factors like what kind of security ?
Questions like this are quite broad, and the ideal answer depends on factors like the application context, the nature of the resources, and the architecture (monolithic vs. microservices). Here is a structured approach covering the essential dimensions of web service security:
A) Transport-Level Security (Data in Transit)
- HTTPS / TLS 1.3: This is the baseline for all modern web services. Enforce HTTPS across all endpoints to encrypt traffic and protect against eavesdropping or Man-in-the-Middle (MitM) attacks.
- Use standard request headers like Authorization: Bearer <token>.
- Standard Approach: Validate incoming tokens via framework security filters (such as Spring Security's filter chain) rather than manual interceptors. If authentication fails, return HTTP 401 Unauthorized; if permissions are insufficient, return HTTP 403 Forbidden.
- ⚠️ Outdated Practice: Writing custom interceptor classes from scratch to manually parse custom headers and enforce roll-your-own authentication logic. Modern applications rely on standardized filter chains and existing framework security modules to avoid introducing security vulnerabilities.
- For web browsers, store tokens or session IDs using HttpOnly, Secure, and SameSite flags on cookies to mitigate Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).
- ⚠️ Outdated Practice: Relying solely on basic domain-level cookies without modern security attributes (HttpOnly, SameSite=Strict/Lax, Secure), which leaves applications vulnerable to CSRF and script injection attacks.
- Leverage enterprise security frameworks like Spring Security for standardized handling of authentication, authorization, CORS, and CSRF protection.
- Use method-level annotations like @PreAuthorize (to check permissions before method execution) and @PostAuthorize (to check permissions or filter output after data is fetched).
- Standardize identity management with industry protocols like OAuth 2.0 and OpenID Connect (OIDC), integrated with Identity Providers (IdPs) like Keycloak, Azure AD, or Okta.
- SAML 2.0 / LDAP: Common in legacy or enterprise single sign-on (SSO) setups, though modern microservices predominantly use stateless JSON Web Tokens (JWT).
- ⚠️ Outdated Practice: Storing access roles in hardcoded .properties files or performing synchronous database lookups inside manual interceptors on every request. In high-concurrency systems, hardcoded role mapping lacks flexibility, and frequent synchronous DB checks introduce severe latency bottlenecks (which can be mitigated using token-based claims or distributed caching like Redis).
- Data Protection: Encrypt sensitive payload data at rest (e.g., AES-256) and sanitize inputs using validation annotations (@Valid, @NotNull) to guard against SQL Injection and XSS attacks.
- API Protection: Implement rate limiting (e.g., Bucket4j or API Gateway throttling) to protect against Denial of Service (DoS) attacks.
- Perimeter Defense: Use an API Gateway (e.g., Spring Cloud Gateway, Kong) to handle edge authentication, rate limiting, and token validation before traffic enters the cluster.
- Inter-Service Security: Secure communication between internal services using mTLS (Mutual TLS) via a Service Mesh (e.g., Istio) or pass signed JWT tokens down the call chain (Token Relay pattern).
