{"id":4851,"date":"2026-02-09T13:47:14","date_gmt":"2026-02-09T10:47:14","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/api-security-hosting-architecture-with-jwt-cors-rate-limiting-and-waf\/"},"modified":"2026-02-09T13:47:14","modified_gmt":"2026-02-09T10:47:14","slug":"api-security-hosting-architecture-with-jwt-cors-rate-limiting-and-waf","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/api-security-hosting-architecture-with-jwt-cors-rate-limiting-and-waf\/","title":{"rendered":"API Security Hosting Architecture with JWT, CORS, Rate Limiting and WAF"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>When you design an API, you are not just writing endpoints; you are defining a security boundary. On shared hosting, <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s or colocation, that boundary is constantly probed by bots, scanners and sometimes real attackers. At dchost.com we often see the same pattern: teams do a great job on business logic, but leave JWT, CORS, rate limiting and WAF rules as an afterthought. The result is fragile APIs that work in development but become risky and hard to operate in production.<\/p>\n<p>In this article we will walk through a practical <strong>API security hosting architecture<\/strong> that combines JSON Web Tokens (JWT), CORS policies, rate limiting and Web Application Firewall (WAF) rules. We will focus on how these pieces fit together on real servers and CDNs, how to configure them safely, and where they should live in your hosting stack. Whether you run a small API on a single VPS or a multi-tenant SaaS across several servers or colocation racks, you can use the same building blocks in a layered way.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#1_The_Role_of_API_Security_in_Your_Hosting_Architecture\"><span class=\"toc_number toc_depth_1\">1<\/span> 1. The Role of API Security in Your Hosting Architecture<\/a><\/li><li><a href=\"#2_JWT_CORS_Rate_Limiting_and_WAF_How_They_Fit_Together\"><span class=\"toc_number toc_depth_1\">2<\/span> 2. JWT, CORS, Rate Limiting and WAF: How They Fit Together<\/a><\/li><li><a href=\"#3_Designing_JWT-Based_Authentication_for_APIs\"><span class=\"toc_number toc_depth_1\">3<\/span> 3. Designing JWT-Based Authentication for APIs<\/a><ul><li><a href=\"#31_JWT_structure_in_simple_terms\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 3.1 JWT structure in simple terms<\/a><\/li><li><a href=\"#32_Where_JWT_keys_live_in_your_hosting_stack\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 3.2 Where JWT keys live in your hosting stack<\/a><\/li><li><a href=\"#33_Short-lived_access_tokens_and_refresh_tokens\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 3.3 Short-lived access tokens and refresh tokens<\/a><\/li><li><a href=\"#34_Authorization_and_scopes_on_the_server\"><span class=\"toc_number toc_depth_2\">3.4<\/span> 3.4 Authorization and scopes on the server<\/a><\/li><li><a href=\"#35_JWT_revocation_and_key_rotation\"><span class=\"toc_number toc_depth_2\">3.5<\/span> 3.5 JWT revocation and key rotation<\/a><\/li><\/ul><\/li><li><a href=\"#4_CORS_Configuration_for_SPAs_and_Mobile_Apps\"><span class=\"toc_number toc_depth_1\">4<\/span> 4. CORS Configuration for SPAs and Mobile Apps<\/a><ul><li><a href=\"#41_Same-origin_vs_cross-origin_in_practice\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 4.1 Same-origin vs cross-origin in practice<\/a><\/li><li><a href=\"#42_Safe_CORS_defaults_for_APIs\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 4.2 Safe CORS defaults for APIs<\/a><\/li><li><a href=\"#43_Preflight_requests_and_hosting_implications\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 4.3 Preflight requests and hosting implications<\/a><\/li><\/ul><\/li><li><a href=\"#5_Rate_Limiting_Strategies_in_Hosting_Environments\"><span class=\"toc_number toc_depth_1\">5<\/span> 5. Rate Limiting Strategies in Hosting Environments<\/a><ul><li><a href=\"#51_What_to_rate_limit_IP_token_user_or_key\"><span class=\"toc_number toc_depth_2\">5.1<\/span> 5.1 What to rate limit: IP, token, user, or key?<\/a><\/li><li><a href=\"#52_Algorithms_and_tools_commonly_used_on_servers\"><span class=\"toc_number toc_depth_2\">5.2<\/span> 5.2 Algorithms and tools commonly used on servers<\/a><\/li><li><a href=\"#53_Protecting_authentication_and_login_endpoints\"><span class=\"toc_number toc_depth_2\">5.3<\/span> 5.3 Protecting authentication and login endpoints<\/a><\/li><\/ul><\/li><li><a href=\"#6_WAF_Rules_Tuned_Specifically_for_APIs\"><span class=\"toc_number toc_depth_1\">6<\/span> 6. WAF Rules Tuned Specifically for APIs<\/a><ul><li><a href=\"#61_What_makes_API_traffic_different\"><span class=\"toc_number toc_depth_2\">6.1<\/span> 6.1 What makes API traffic different<\/a><\/li><li><a href=\"#62_API-specific_WAF_rules_to_consider\"><span class=\"toc_number toc_depth_2\">6.2<\/span> 6.2 API-specific WAF rules to consider<\/a><\/li><li><a href=\"#63_Integrating_WAF_with_JWT_and_rate_limiting\"><span class=\"toc_number toc_depth_2\">6.3<\/span> 6.3 Integrating WAF with JWT and rate limiting<\/a><\/li><\/ul><\/li><li><a href=\"#7_Putting_It_All_Together_Reference_Architectures_on_dchostcom\"><span class=\"toc_number toc_depth_1\">7<\/span> 7. Putting It All Together: Reference Architectures on dchost.com<\/a><ul><li><a href=\"#71_Small_API_on_a_single_VPS\"><span class=\"toc_number toc_depth_2\">7.1<\/span> 7.1 Small API on a single VPS<\/a><\/li><li><a href=\"#72_Public_API_for_SPA_mobile_app\"><span class=\"toc_number toc_depth_2\">7.2<\/span> 7.2 Public API for SPA + mobile app<\/a><\/li><li><a href=\"#73_Multi-tenant_SaaS_on_multiple_servers_or_colocation\"><span class=\"toc_number toc_depth_2\">7.3<\/span> 7.3 Multi-tenant SaaS on multiple servers or colocation<\/a><\/li><\/ul><\/li><li><a href=\"#8_Operational_Practices_Logs_Monitoring_and_Access_Control\"><span class=\"toc_number toc_depth_1\">8<\/span> 8. Operational Practices: Logs, Monitoring and Access Control<\/a><ul><li><a href=\"#81_Logging_the_right_data_without_drowning\"><span class=\"toc_number toc_depth_2\">8.1<\/span> 8.1 Logging the right data (without drowning)<\/a><\/li><li><a href=\"#82_Monitoring_and_alerting\"><span class=\"toc_number toc_depth_2\">8.2<\/span> 8.2 Monitoring and alerting<\/a><\/li><li><a href=\"#83_Securing_access_to_hosting_panels_and_servers\"><span class=\"toc_number toc_depth_2\">8.3<\/span> 8.3 Securing access to hosting panels and servers<\/a><\/li><\/ul><\/li><li><a href=\"#9_Summary_and_Next_Steps\"><span class=\"toc_number toc_depth_1\">9<\/span> 9. Summary and Next Steps<\/a><\/li><\/ul><\/div>\n<h2><span id=\"1_The_Role_of_API_Security_in_Your_Hosting_Architecture\">1. The Role of API Security in Your Hosting Architecture<\/span><\/h2>\n<p>APIs are now the primary entry point into many applications. Mobile apps, single-page applications (SPAs), partner integrations and internal tools all depend on them. That means your hosting architecture must treat the API as a first-class citizen from a security perspective, not as a sidecar to the website.<\/p>\n<p>A solid API security architecture on your hosting stack should answer these questions:<\/p>\n<ul>\n<li><strong>Who<\/strong> is calling the API? (Authentication with JWT or similar)<\/li>\n<li><strong>What<\/strong> are they allowed to do? (Authorization and scopes)<\/li>\n<li><strong>From where<\/strong> can they call it? (CORS and network controls)<\/li>\n<li><strong>How often<\/strong> can they call it? (Rate limiting and quotas)<\/li>\n<li><strong>What happens<\/strong> when someone misuses it? (WAF rules, blocking and logging)<\/li>\n<\/ul>\n<p>On the hosting side, these answers get translated into concrete components:<\/p>\n<ul>\n<li><strong>Application layer<\/strong>: your API code handles JWT, authorization checks and business logic.<\/li>\n<li><strong>Reverse proxy \/ API gateway<\/strong> (Nginx, Envoy, etc.): enforces CORS, rate limiting and sometimes JWT validation.<\/li>\n<li><strong>CDN \/ edge layer<\/strong>: optional extra rate limiting, bot filtering and WAF rules close to the user.<\/li>\n<li><strong>Network and OS layer<\/strong>: firewall rules, SSH protection and hardening of the VPS or dedicated server.<\/li>\n<\/ul>\n<p>We already discussed server-side measures such as <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-guvenlik-sertlestirme-kontrol-listesi-sshd_config-fail2ban-ve-root-erisimini-kapatmak\/\">VPS security hardening with sshd_config and Fail2ban<\/a> and <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-hsts-csp-x-frame-options-ve-digerleri-nasil-ayarlanir\/\">HTTP security headers on shared hosting and VPS<\/a>. Here we will zoom into the API-specific layer.<\/p>\n<h2><span id=\"2_JWT_CORS_Rate_Limiting_and_WAF_How_They_Fit_Together\">2. JWT, CORS, Rate Limiting and WAF: How They Fit Together<\/span><\/h2>\n<p>Before diving into each piece, it helps to see how they interact during a real request.<\/p>\n<ol>\n<li>The client (browser SPA, mobile app or server-to-server integration) sends a request to <code>api.yourdomain.com<\/code>.<\/li>\n<li>Your CDN or reverse proxy receives it and immediately applies <strong>WAF rules<\/strong> (blocking obvious attacks) and <strong>rate limiting<\/strong> (throttling abusive clients or IPs).<\/li>\n<li>The proxy checks <strong>CORS rules<\/strong> for browser-based calls, answering preflight requests and setting the right headers.<\/li>\n<li>The request reaches the application, which validates the <strong>JWT<\/strong> (signature, expiry, audience, scopes, etc.) and performs authorization checks.<\/li>\n<li>If allowed, the app executes the business logic and returns a response. The proxy\/CDN again applies WAF filters on response anomalies if configured.<\/li>\n<\/ol>\n<p>Each layer has a clear job:<\/p>\n<ul>\n<li><strong>JWT<\/strong>: proves identity and carries claims (who you are, what you can do).<\/li>\n<li><strong>CORS<\/strong>: controls which browser frontends can call the API.<\/li>\n<li><strong>Rate limiting<\/strong>: controls how much traffic each identity, API key or IP can send.<\/li>\n<li><strong>WAF<\/strong>: detects and blocks malicious patterns that bypass simple checks.<\/li>\n<\/ul>\n<p>If one fails, others still provide protection. This layered approach is the same mindset we use when we design secure hosting setups at dchost.com.<\/p>\n<h2><span id=\"3_Designing_JWT-Based_Authentication_for_APIs\">3. Designing JWT-Based Authentication for APIs<\/span><\/h2>\n<p><strong>JSON Web Tokens (JWT)<\/strong> are compact, signed tokens that the client includes with each API request, usually in the <code>Authorization: Bearer &lt;token&gt;<\/code> header. They are widely used for stateless authentication.<\/p>\n<h3><span id=\"31_JWT_structure_in_simple_terms\">3.1 JWT structure in simple terms<\/span><\/h3>\n<p>A JWT has three parts, each Base64URL encoded:<\/p>\n<ul>\n<li><strong>Header<\/strong>: algorithm and token type (e.g. <code>{\"alg\":\"HS256\",\"typ\":\"JWT\"}<\/code>).<\/li>\n<li><strong>Payload<\/strong>: claims such as user ID, roles, expiration time.<\/li>\n<li><strong>Signature<\/strong>: cryptographic signature over header + payload using a secret or private key.<\/li>\n<\/ul>\n<p>On the hosting side, the critical piece is <strong>how and where you store the key material<\/strong> (secrets or private keys) that sign and verify tokens.<\/p>\n<h3><span id=\"32_Where_JWT_keys_live_in_your_hosting_stack\">3.2 Where JWT keys live in your hosting stack<\/span><\/h3>\n<p>Never hard-code JWT secrets in your source code or commit them to Git. On a VPS or dedicated server, we recommend:<\/p>\n<ul>\n<li>Storing JWT secrets or private keys in <strong>environment variables<\/strong> or secure files outside the web root.<\/li>\n<li>Restricting file permissions so only the application user can read them.<\/li>\n<li>Using a secret management pattern instead of plain <code>.env<\/code> files, as described in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/env-dosyalarinin-otesinde-vps-uzerinde-gizli-bilgi-yonetimi\/\">secrets management beyond .env files on a VPS<\/a>.<\/li>\n<li>If you use colocation or dedicated servers for compliance reasons, integrating with a Hardware Security Module (HSM) or external KMS for key storage.<\/li>\n<\/ul>\n<p>On a multi-node architecture, ensure all API servers share the same public key (for asymmetric JWT) or secret (for symmetric JWT), distributed by your CI\/CD pipeline or configuration management, not manually copied by SSH.<\/p>\n<h3><span id=\"33_Short-lived_access_tokens_and_refresh_tokens\">3.3 Short-lived access tokens and refresh tokens<\/span><\/h3>\n<p>A common hosting-side mistake is using long-lived JWTs because rotating them seems complex. Instead, use:<\/p>\n<ul>\n<li><strong>Short-lived access tokens<\/strong>: e.g. 5\u201315 minutes. These are sent with every API call.<\/li>\n<li><strong>Refresh tokens<\/strong>: stored more securely (often HTTP-only, same-site cookies or secure mobile storage) and exchanged for new access tokens.<\/li>\n<\/ul>\n<p>This design limits the damage if an access token leaks through access logs, browser extensions or a misconfigured CORS policy. Rotation logic runs on your API servers hosted at dchost.com; scaling them horizontally just means more nodes can handle the same token validation rules.<\/p>\n<h3><span id=\"34_Authorization_and_scopes_on_the_server\">3.4 Authorization and scopes on the server<\/span><\/h3>\n<p>JWT only tells you <em>who<\/em> the caller is; authorization decides <em>what<\/em> they can do. Implement authorization in your API code, not just in the frontend. Typical patterns:<\/p>\n<ul>\n<li><strong>Role-based access control (RBAC)<\/strong>: roles like <code>admin<\/code>, <code>user<\/code>, <code>partner<\/code> in JWT claims.<\/li>\n<li><strong>Scope-based access<\/strong>: permissions like <code>orders:read<\/code>, <code>orders:write<\/code>, <code>billing:read<\/code>.<\/li>\n<li><strong>Tenant isolation<\/strong>: a <code>tenant_id<\/code> claim, checked on every query for multi-tenant SaaS.<\/li>\n<\/ul>\n<p>On the hosting architecture side, this means every API instance (on any VPS or dedicated server) must run identical authorization logic and share the same understanding of roles and scopes. You should also log authorization failures centrally for later analysis.<\/p>\n<h3><span id=\"35_JWT_revocation_and_key_rotation\">3.5 JWT revocation and key rotation<\/span><\/h3>\n<p>JWT is stateless, which is great for performance but makes revocation tricky. Some strategies:<\/p>\n<ul>\n<li>Use <strong>short expirations<\/strong> so compromised tokens become useless quickly.<\/li>\n<li>Maintain a <strong>revocation list<\/strong> in Redis or your database for high-risk cases (e.g. admin tokens) and check it on each request.<\/li>\n<li>Implement <strong>key rotation<\/strong>: use a <code>kid<\/code> (key ID) in JWT header; your servers keep multiple keys and know which one to use to verify each token.<\/li>\n<\/ul>\n<p>When you host APIs on multiple servers at dchost.com, key rotation requires careful rollout: deploy new configs to all nodes, start issuing tokens with the new key, keep the old key available for verification until old tokens expire, then remove it. Automate this with your deployment pipeline.<\/p>\n<h2><span id=\"4_CORS_Configuration_for_SPAs_and_Mobile_Apps\">4. CORS Configuration for SPAs and Mobile Apps<\/span><\/h2>\n<p><strong>CORS (Cross-Origin Resource Sharing)<\/strong> is a browser security mechanism that controls which origins (scheme + host + port) can send JavaScript requests to your API. It does not protect server-to-server calls, only browser-based ones.<\/p>\n<h3><span id=\"41_Same-origin_vs_cross-origin_in_practice\">4.1 Same-origin vs cross-origin in practice<\/span><\/h3>\n<p>Imagine this setup:<\/p>\n<ul>\n<li>SPA frontend at <code>https:\/\/app.example.com<\/code><\/li>\n<li>API at <code>https:\/\/api.example.com<\/code><\/li>\n<\/ul>\n<p>These are different subdomains, so they are <strong>different origins<\/strong>. Your API must respond with CORS headers like <code>Access-Control-Allow-Origin<\/code> for the browser to accept responses.<\/p>\n<p>One robust pattern is to host SPA and API under the same origin (e.g. API under <code>\/api<\/code>) to reduce CORS complexity. We discussed the infrastructure side in detail in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/react-vue-ve-angular-single-page-applicationlari-ayni-alan-adinda-api-ile-host-etmek-nginx-yonlendirme-ve-ssl-mimarisi\/\">hosting SPA and API on the same domain with Nginx routing and SSL<\/a>.<\/p>\n<h3><span id=\"42_Safe_CORS_defaults_for_APIs\">4.2 Safe CORS defaults for APIs<\/span><\/h3>\n<p>Some hosting panels and frameworks allow you to quickly enable CORS with <code>*<\/code> (allow all). That is rarely a good idea. Safer guidelines:<\/p>\n<ul>\n<li><strong>Explicit origins<\/strong>: list the exact allowed origins, e.g. <code>https:\/\/app.example.com<\/code> and <code>https:\/\/admin.example.com<\/code>.<\/li>\n<li><strong>Per-environment configs<\/strong>: different CORS lists for staging and production; don\u2019t leave <code>localhost<\/code> origins enabled on production.<\/li>\n<li><strong>Limit methods and headers<\/strong>: only allow what you need (e.g. <code>GET, POST, PUT, DELETE<\/code>, not <code>OPTIONS, TRACE<\/code> unless required).<\/li>\n<li><strong>Control credentials<\/strong>: use <code>Access-Control-Allow-Credentials: true<\/code> only when you really need cookies or HTTP auth, and <em>never<\/em> combine it with <code>Access-Control-Allow-Origin: *<\/code>.<\/li>\n<\/ul>\n<p>Implement CORS either in your API framework or at the reverse proxy layer (Nginx, Caddy, etc.). On a multi-tenant VPS serving several APIs, centralizing CORS rules at the proxy can simplify management, but remember that each vhost may need its own origin list.<\/p>\n<h3><span id=\"43_Preflight_requests_and_hosting_implications\">4.3 Preflight requests and hosting implications<\/span><\/h3>\n<p>Browsers send <strong>preflight<\/strong> <code>OPTIONS<\/code> requests to check CORS permissions before the real request. Your hosting configuration must:<\/p>\n<ul>\n<li>Allow <code>OPTIONS<\/code> method through the firewall and reverse proxy.<\/li>\n<li>Return appropriate CORS headers for <code>OPTIONS<\/code> requests quickly (often from the proxy without hitting the app).<\/li>\n<li>Avoid logging preflight noise excessively in your main access logs to keep them readable.<\/li>\n<\/ul>\n<p>On high-traffic APIs, serving preflight responses directly from Nginx on your VPS or dedicated server reduces load on backend application processes.<\/p>\n<h2><span id=\"5_Rate_Limiting_Strategies_in_Hosting_Environments\">5. Rate Limiting Strategies in Hosting Environments<\/span><\/h2>\n<p><strong>Rate limiting<\/strong> controls how many requests a client can make in a given time window. It protects your API from abuse, brute-force attacks and accidental overload caused by buggy clients or integrations.<\/p>\n<h3><span id=\"51_What_to_rate_limit_IP_token_user_or_key\">5.1 What to rate limit: IP, token, user, or key?<\/span><\/h3>\n<p>You can apply rate limits on different dimensions:<\/p>\n<ul>\n<li><strong>Per IP address<\/strong>: simple and effective for anonymous APIs but weaker behind NAT or mobile carriers.<\/li>\n<li><strong>Per API key or JWT subject (user ID)<\/strong>: fairer for authenticated APIs; each user gets their own quota.<\/li>\n<li><strong>Per route<\/strong>: stricter limits on expensive endpoints (e.g. search, report generation) than on simple reads.<\/li>\n<\/ul>\n<p>In hosting terms, the closer to the edge you implement rate limiting, the less load reaches your origin servers. At the same time, origin-level limits (on the VPS itself) can be more granular because they have access to JWT claims and full request context. We explored this in more detail in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/api-ve-mikroservisler-icin-rate-limiting-stratejileri-nginx-cloudflare-ve-redis-ile-trafik-kontrolu\/\">rate limiting strategies for APIs and microservices with Nginx, Cloudflare and Redis<\/a>.<\/p>\n<h3><span id=\"52_Algorithms_and_tools_commonly_used_on_servers\">5.2 Algorithms and tools commonly used on servers<\/span><\/h3>\n<p>Popular algorithms include:<\/p>\n<ul>\n<li><strong>Token bucket<\/strong>: clients accumulate tokens over time and spend one per request.<\/li>\n<li><strong>Leaky bucket<\/strong>: smooths bursts by processing requests at a fixed rate.<\/li>\n<li><strong>Fixed window<\/strong>: counts requests in a simple time window (e.g. 100 requests per minute).<\/li>\n<li><strong>Sliding window<\/strong>: more fair but slightly more complex to implement.<\/li>\n<\/ul>\n<p>On a single VPS, you can implement rate limiting with:<\/p>\n<ul>\n<li>Nginx <code>limit_req<\/code> and <code>limit_conn<\/code> directives, using shared memory zones.<\/li>\n<li>Your application framework plus Redis to track counters per user or token.<\/li>\n<\/ul>\n<p>On a multi-server architecture (dedicated or multi-VPS), a centralized store like Redis or a dedicated API gateway helps ensure consistent limits across all nodes. You must also decide what response to send when limits are hit: generally <code>429 Too Many Requests<\/code> with clear <code>Retry-After<\/code> headers.<\/p>\n<h3><span id=\"53_Protecting_authentication_and_login_endpoints\">5.3 Protecting authentication and login endpoints<\/span><\/h3>\n<p>Login, password reset and token issuance endpoints are frequent attack targets. At dchost.com we usually recommend:<\/p>\n<ul>\n<li>Very strict <strong>rate limits per IP<\/strong> and per user identifier (email\/username) for these routes.<\/li>\n<li>Additional WAF rules for <code>\/login<\/code>, <code>\/auth\/*<\/code>, <code>\/token<\/code> endpoints.<\/li>\n<li>Separate monitoring dashboards and alerts when these endpoints are under pressure.<\/li>\n<\/ul>\n<p>This can be combined with <strong>zero-trust access<\/strong> for admin panels and internal APIs, as we described in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-trust-ile-hosting-ve-sunucu-erisimini-guvenceye-almak\/\">zero-trust access to hosting panels and servers<\/a>. The idea is to make it hard for attackers to even reach sensitive endpoints without additional identity checks.<\/p>\n<h2><span id=\"6_WAF_Rules_Tuned_Specifically_for_APIs\">6. WAF Rules Tuned Specifically for APIs<\/span><\/h2>\n<p>A <strong>Web Application Firewall (WAF)<\/strong> inspects HTTP requests and responses to detect malicious patterns such as SQL injection, XSS, path traversal and other attack signatures. For APIs, WAF rules must be tuned a bit differently than for classic HTML websites.<\/p>\n<h3><span id=\"61_What_makes_API_traffic_different\">6.1 What makes API traffic different<\/span><\/h3>\n<p>API traffic has characteristics that your WAF should understand:<\/p>\n<ul>\n<li>Mostly <strong>JSON bodies<\/strong>, not HTML forms.<\/li>\n<li>Frequent use of <strong>PUT, PATCH, DELETE<\/strong> methods.<\/li>\n<li>Heavy use of <strong>custom headers<\/strong>, JWTs and API keys.<\/li>\n<li>Machine-generated patterns (mobile apps, scripts) where some false positives can be tolerated, but block pages must be API-friendly.<\/li>\n<\/ul>\n<p>If you use ModSecurity or a CDN WAF, make sure the ruleset is aware of JSON body parsing and OWASP API Top 10 scenarios, not just classic OWASP Top 10 for web forms. For a broader overview of WAF concepts, see our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/web-uygulama-guvenlik-duvari-waf-nedir-cloudflare-waf-ve-modsecurity-ile-web-sitesi-koruma-rehberi\/\">What is a Web Application Firewall (WAF)?<\/a>.<\/p>\n<h3><span id=\"62_API-specific_WAF_rules_to_consider\">6.2 API-specific WAF rules to consider<\/span><\/h3>\n<p>When tuning WAF rules for APIs hosted on VPS or dedicated servers, we typically apply:<\/p>\n<ul>\n<li><strong>Strict JSON validation<\/strong>: reject malformed JSON early.<\/li>\n<li><strong>Size limits<\/strong> per endpoint: e.g. max 1 MB for standard endpoints, higher only where file uploads are expected.<\/li>\n<li><strong>Method whitelisting<\/strong> per path: if <code>\/orders<\/code> doesn\u2019t need <code>DELETE<\/code>, block it at WAF level.<\/li>\n<li><strong>Schema-aware checks<\/strong> for critical fields (IDs, file paths, SQL fragments) if your WAF or API gateway supports it.<\/li>\n<\/ul>\n<p>For large deployments, we rely heavily on ModSecurity with the OWASP Core Rule Set (CRS), tuned as described in our guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/modsecurity-ve-owasp-crs-ile-wafi-uysallastirmak-yanlis-pozitifleri-nasil-ehlilestirir-performansi-ne-zaman-ucururuz\/\">The Calm WAF: how to tune ModSecurity + OWASP CRS<\/a>. The same tuning principles apply to JSON APIs as well: start in logging-only mode, watch false positives, then gradually enforce.<\/p>\n<h3><span id=\"63_Integrating_WAF_with_JWT_and_rate_limiting\">6.3 Integrating WAF with JWT and rate limiting<\/span><\/h3>\n<p>Your WAF doesn\u2019t have to be blind to authentication. Some advanced setups:<\/p>\n<ul>\n<li>Write WAF rules that consider <strong>JWT claims<\/strong> (e.g. block requests where a low-privilege user tries admin-only routes).<\/li>\n<li>Use WAF to detect <strong>behavioral anomalies<\/strong> (strange spikes on certain routes) and then tighten <strong>rate limits<\/strong> dynamically.<\/li>\n<li>Ensure WAF logs include JWT <code>sub<\/code> or user ID (in a privacy-safe way) to correlate incidents.<\/li>\n<\/ul>\n<p>This combination of JWT-aware WAF and rate limiting gives you a powerful shield, especially when APIs serve high-value actions like payments, order management or internal admin operations.<\/p>\n<h2><span id=\"7_Putting_It_All_Together_Reference_Architectures_on_dchostcom\">7. Putting It All Together: Reference Architectures on dchost.com<\/span><\/h2>\n<p>Let\u2019s translate these ideas into concrete hosting architectures you can implement on dchost.com. We will look at three typical scenarios.<\/p>\n<h3><span id=\"71_Small_API_on_a_single_VPS\">7.1 Small API on a single VPS<\/span><\/h3>\n<p>This is common for early-stage projects or internal APIs.<\/p>\n<ul>\n<li><strong>Hosting<\/strong>: 1 VPS with Nginx (or Apache) + application runtime (PHP\/Laravel, Node.js, etc.) + Redis.<\/li>\n<li><strong>JWT<\/strong>: application framework handles login, token issuance and validation; secrets stored via a safe pattern as in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/env-dosyalarinin-otesinde-vps-uzerinde-gizli-bilgi-yonetimi\/\">secrets management beyond .env<\/a> article.<\/li>\n<li><strong>CORS<\/strong>: implemented in Nginx or the framework; explicit list of allowed origins.<\/li>\n<li><strong>Rate limiting<\/strong>: Nginx <code>limit_req<\/code> for per-IP limits and Redis counters for per-user limits.<\/li>\n<li><strong>WAF<\/strong>: ModSecurity with OWASP CRS on the same VPS, tuned for JSON APIs.<\/li>\n<\/ul>\n<p>This setup is simple to manage and already provides a solid security baseline. When traffic grows, you can scale vertically (more CPU\/RAM) or move to a multi-VPS architecture without rewriting your security logic.<\/p>\n<h3><span id=\"72_Public_API_for_SPA_mobile_app\">7.2 Public API for SPA + mobile app<\/span><\/h3>\n<p>Here you typically have a web frontend, mobile apps and maybe third-party integrations.<\/p>\n<ul>\n<li><strong>Hosting<\/strong>: 1\u20133 VPS nodes for the API behind a reverse proxy\/load balancer; 1 VPS or shared hosting for the SPA; optional CDN for static assets.<\/li>\n<li><strong>JWT<\/strong>: short-lived access tokens, refresh tokens with rotating secrets; centralized key distribution.<\/li>\n<li><strong>CORS<\/strong>: strict origin lists for production SPAs and mobile debug hosts; separate config for staging.<\/li>\n<li><strong>Rate limiting<\/strong>: edge-level per-IP limits and origin-level per-user and per-key limits using Redis.<\/li>\n<li><strong>WAF<\/strong>: WAF in front of the load balancer (CDN or reverse proxy) + ModSecurity on origin for deeper inspection.<\/li>\n<\/ul>\n<p>To keep login and session endpoints extra safe, add stronger limits and more restrictive WAF rules. Combine this with safe <a href=\"https:\/\/www.dchost.com\/blog\/en\/http-guvenlik-basliklari-rehberi-hsts-csp-x-frame-options-ve-digerleri-nasil-ayarlanir\/\">HTTP security headers (HSTS, CSP, etc.)<\/a> on both the SPA and API domains.<\/p>\n<h3><span id=\"73_Multi-tenant_SaaS_on_multiple_servers_or_colocation\">7.3 Multi-tenant SaaS on multiple servers or colocation<\/span><\/h3>\n<p>For larger SaaS platforms, we often see:<\/p>\n<ul>\n<li><strong>Hosting<\/strong>: dedicated servers or colocation for core databases, plus a pool of VPS or dedicated nodes for API workers and background jobs.<\/li>\n<li><strong>JWT<\/strong>: multi-tenant aware tokens with <code>tenant_id<\/code> claims; different scopes for admin, owner and end-users.<\/li>\n<li><strong>CORS<\/strong>: dynamic origin validation for customer-branded frontends (e.g. <code>https:\/\/customer1.saas.com<\/code>, <code>https:\/\/customer2.saas.com<\/code>).<\/li>\n<li><strong>Rate limiting<\/strong>: per-tenant quotas implemented via Redis; different tiers (Free, Pro, Enterprise) with different limits.<\/li>\n<li><strong>WAF<\/strong>: layered WAF (edge + origin) tuned carefully to reduce false positives, following the best practices in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/modsecurity-ve-owasp-crs-ile-wafi-uysallastirmak-yanlis-pozitifleri-nasil-ehlilestirir-performansi-ne-zaman-ucururuz\/\">tuning ModSecurity and OWASP CRS<\/a>.<\/li>\n<\/ul>\n<p>Such environments also benefit from centralized logging and alerting (ELK\/Loki, Prometheus, Grafana) so you can spot anomalies across all tenants. This ties directly into security monitoring and incident response.<\/p>\n<h2><span id=\"8_Operational_Practices_Logs_Monitoring_and_Access_Control\">8. Operational Practices: Logs, Monitoring and Access Control<\/span><\/h2>\n<p>Even the best JWT, CORS, rate limiting and WAF configuration can be undermined by poor operations. API security is a continuous process, not a one-time setup.<\/p>\n<h3><span id=\"81_Logging_the_right_data_without_drowning\">8.1 Logging the right data (without drowning)<\/span><\/h3>\n<p>Your hosting architecture should log:<\/p>\n<ul>\n<li>Authentication events (logins, refreshes, failures, revocations).<\/li>\n<li>Rate limit hits (who was throttled, on which endpoint, from which IP).<\/li>\n<li>WAF blocks (rule ID, endpoint, client IP, request snippets).<\/li>\n<li>Admin and sensitive operations (role changes, key creation, tenant configuration changes).<\/li>\n<\/ul>\n<p>Store logs centrally, not only on each VPS, to simplify incident analysis. You can then build alerts for suspicious patterns: sudden spikes in 401\/403 errors, repeated WAF blocks on specific endpoints, or abnormal rate limiting trends.<\/p>\n<h3><span id=\"82_Monitoring_and_alerting\">8.2 Monitoring and alerting<\/span><\/h3>\n<p>Combine infrastructure-level monitoring (CPU, RAM, disk, network) with application-level metrics (requests per second, error rates, latency). Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/merkezi-sunucu-izleme-ve-alarm-mimarisi\/\">centralized server monitoring and alerting with Prometheus, Grafana and Zabbix<\/a> provides a good starting point. For APIs specifically:<\/p>\n<ul>\n<li>Track <strong>per-endpoint latency<\/strong> and error rate (especially 401\/403\/429\/5xx).<\/li>\n<li>Monitor <strong>rate limit usage<\/strong> per tenant or API key.<\/li>\n<li>Set alerts when <strong>WAF block rates<\/strong> spike unexpectedly.<\/li>\n<\/ul>\n<p>This gives you early warning that something is wrong, either on the client side (buggy app) or on the attacker side (new attack wave).<\/p>\n<h3><span id=\"83_Securing_access_to_hosting_panels_and_servers\">8.3 Securing access to hosting panels and servers<\/span><\/h3>\n<p>Finally, don\u2019t forget the human side: who can log into your control panel or SSH into your VPS or dedicated server? A misconfigured firewall or leaked SSH key can bypass all your API-level protections. We strongly recommend adopting the principles we described in <a href=\"https:\/\/www.dchost.com\/blog\/en\/zero-trust-ile-hosting-ve-sunucu-erisimini-guvenceye-almak\/\">Zero-Trust access to hosting panels and servers<\/a>:<\/p>\n<ul>\n<li>Use strong 2FA for hosting panels.<\/li>\n<li>Restrict SSH by IP, keys and roles.<\/li>\n<li>Log and review admin access regularly.<\/li>\n<\/ul>\n<p>This way, the infrastructure that runs your JWT, CORS, rate limiting and WAF layers remains trustworthy.<\/p>\n<h2><span id=\"9_Summary_and_Next_Steps\">9. Summary and Next Steps<\/span><\/h2>\n<p>JWT, CORS, rate limiting and WAF rules are not isolated checkboxes; together they form the core of a robust <strong>API security hosting architecture<\/strong>. JWT tells you who is calling and what they are allowed to do. CORS controls which browser frontends may talk to your API. Rate limiting keeps abusive or buggy clients from overwhelming your servers. WAF rules add a smart filter that recognizes and blocks known attack patterns, especially around JSON APIs and authentication endpoints.<\/p>\n<p>On the hosting side, these concepts become concrete Nginx directives, ModSecurity rule sets, Redis counters, log pipelines and TLS configurations. Whether you run a small API on a single VPS, a growing SaaS across multiple VPS nodes, or a high-compliance platform on dedicated servers or colocation, the same layered approach applies. Start with sane defaults, tune them based on real traffic and keep everything under good monitoring and access control.<\/p>\n<p>If you are planning a new API project or want to harden an existing one, our team at dchost.com can help you design the right combination of VPS, dedicated servers and network layout, then map JWT, CORS, rate limiting and WAF rules onto that architecture. Reach out to us with your current setup and requirements; we can review your existing configuration, suggest improvements and help you move towards a secure, scalable hosting design that you can confidently build on.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>When you design an API, you are not just writing endpoints; you are defining a security boundary. On shared hosting, VPS, dedicated servers or colocation, that boundary is constantly probed by bots, scanners and sometimes real attackers. At dchost.com we often see the same pattern: teams do a great job on business logic, but leave [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4852,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4851","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4851","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4851"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4851\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4852"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4851"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4851"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4851"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}