DDoS and bot attacks

• Website Security
• Updated: 4 October 2026
• About 9 min read

Concepts and layers of defence

1. 1

   Tell the types of attack apart

   • Volumetric attacks: So much traffic is sent that it fills the network connection. This traffic has to be filtered in the network of the hosting provider or the CDN before it reaches your server; no setting on the server itself can stop it.
   • Application-layer attacks: Requests that look like those of a normal visitor but are expensive for the server (search, filtering, login, large reports) are sent over and over again. Even a small amount of traffic can exhaust PHP and the database.
   • Malicious bots: Password guessing, unwanted form submissions, content and price scraping, vulnerability scanning. Each one looks harmless on its own, but together they consume resources.

   : Enlarge

2. 2

   Filter traffic before it reaches the server

   CDN (content delivery network) and WAF (web application firewall) services sit between the visitor and your server: they serve static content from their own servers, filter suspicious requests and hide your server's real IP address. Cloudflare is a common example of this kind of service; many hosting companies offer similar protection too.

   : Enlarge

3. 3

   Answer every request cheaply

   A cache serves a ready-made copy instead of rebuilding the same page on every request. Rate limiting restricts how many requests a source can make in a given period. Together, the two greatly reduce the impact of application-layer attacks and heavy bot traffic.

   : Enlarge

4. 4

   Have a plan for the moment of attack

   Decide in advance who will make the call during an attack, which settings will be switched on and where customers will be kept informed. Without a plan, the first hour is lost to panic.

   : Enlarge

Signs: how do you notice it?

• The site suddenly becomes very slow or returns 502, 503 or 504 errors; on the server, CPU, memory or database connections hit their limits.
• The access log shows an unusual number of requests to the same address, with the same browser identifier (user agent) or from the same IP block.
• Traffic rises abruptly from countries or at times of day when you do not normally have visitors.
• Requests to a single page, such as search, filtering or login, make up most of the total traffic.
• A large number of meaningless submissions arrive through the contact form; failed attempts on the login page increase.

Not every slowdown is an attack. A campaign, a piece of content shared on social media or a search engine bot crawling intensively can produce the same picture. Look at the logs before you decide: which address are the requests going to, from which sources and how often?

Points to watch when using a CDN and WAF

• Protect your real IP address: After you move to a CDN, the server's IP address can still be discovered from old DNS records, email headers or subdomains. If possible, accept web requests on the server only from the CDN's IP ranges.
• Read the real visitor IP correctly: Behind a CDN, REMOTE_ADDR is the CDN's address. Read the visitor's address from the header the CDN passes on, but trust that header only if the request really comes from the CDN; otherwise anyone can send a forged header.
• Attack mode: Many services offer a mode that shows visitors an extra verification step during an attack. Find out in advance where it is switched on.
• Write rules with restraint: Country blocking or strict bot rules can also block real customers and search engines. After a change, try your site from different networks.

Caching: the cheapest defence

Define long-lived browser and CDN caching for image, style and script files. Use page caching on pages that are the same for everyone (home page, product and blog pages); that way the request never reaches PHP and the database at all.

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/webp "access plus 90 days"
    ExpiresByType image/jpeg "access plus 90 days"
    ExpiresByType image/png  "access plus 90 days"
    ExpiresByType text/css   "access plus 30 days"
    ExpiresByType application/javascript "access plus 30 days"
</IfModule>

• Do not cache pages that are specific to a logged-in user (basket, account).
• On pages whose results can grow without limit (search, filters), cap the number of records per page and the page number.
• Cache the results of expensive queries, even if only for a short time.

Rate limiting

Rate limiting is most effective at the CDN, WAF or web server level, because the request is rejected before it reaches PHP. Look for a "rate limiting" option in your hosting panel or your CDN settings. At the application level, it makes sense to set separate limits on endpoints that are expensive or open to abuse, such as login, registration, password reset, the contact form and search.

<?php
// Table: istek_sayaci (anahtar VARCHAR(100), zaman DATETIME, INDEX(anahtar, zaman))
// Example: at most 5 submissions per IP in 10 minutes for the contact form
function sinirAsildi(PDO $pdo, string $anahtar, int $azami, int $dakika): bool
{
    $sorgu = $pdo->prepare(
        'SELECT COUNT(*) FROM istek_sayaci WHERE anahtar = ? AND zaman > (NOW() - INTERVAL ? MINUTE)'
    );
    $sorgu->bindValue(1, $anahtar);
    $sorgu->bindValue(2, $dakika, PDO::PARAM_INT);
    $sorgu->execute();
    if ((int) $sorgu->fetchColumn() >= $azami) {
        return true;
    }
    $pdo->prepare('INSERT INTO istek_sayaci (anahtar, zaman) VALUES (?, NOW())')->execute([$anahtar]);
    return false;
}

$anahtar = 'iletisim:' . ($_SERVER['REMOTE_ADDR'] ?? '');
if (sinirAsildi($pdo, $anahtar, 5, 10)) {
    http_response_code(429);
    header('Retry-After: 600');
    echo 'Too many submissions in a short time. Please try again a little later.';
    return;
}

Returning a 429 Too Many Requests response and a Retry-After header when the limit is exceeded lets well-behaved clients know when to try again. In the example the counter is kept in the database; on busy sites an in-memory store (e.g. APCu or Redis) is more suitable.

Limiting bad bots

• robots.txt is not a security measure. It only gives directions to bots that follow the rules; malicious bots ignore it. What is more, writing the addresses you want to hide into this file announces those addresses to everyone.
• Protect your forms: An invisible trap field (honeypot), a check on how quickly the form was submitted and, where necessary, a captcha reduce automated form submissions.
• Limit login attempts: See Login and session security.
• Close unused endpoints: API addresses you do not use and old scripts are targets for automated scans.
• Do not block search engine bots: Whether a bot really belongs to the search engine it claims to be can be checked with the verification methods the search engines publish.

A simple honeypot field example:

<form method="post" action="iletisim-gonder">
    <!-- A field people do not see: bots usually fill it in -->
    <div style="position:absolute;left:-9999px" aria-hidden="true">
        <label for="web_adresi">Leave this field empty</label>
        <input type="text" id="web_adresi" name="web_adresi" tabindex="-1" autocomplete="off">
    </div>
    <!-- ... the real fields ... -->
</form>
<?php
// On the server: if the field is filled in, silently ignore the submission
if (trim((string) ($_POST['web_adresi'] ?? '')) !== '') {
    http_response_code(200);
    echo 'Your message has been received.';
    return;
}

What to do during an attack

1. Verify: Look at the logs and the server resources; is the problem really a flood of requests, or is it a software bug or a full disk?
2. Call your hosting provider: Only they or your CDN can filter a volumetric attack. Pass on the time the attack started and the signs you are seeing.
3. Raise the protection: Switch on the attack mode of your CDN or WAF; tighten the rate limits.
4. Temporarily restrict expensive pages: Close pages such as search, filters and reports, or open them only to logged-in users.
5. Inform your customers: Give a brief update through a channel outside the site, such as social media or email.
6. Do not respond to payment demands: Paying in response to messages that ask for money to stop the attack does not guarantee the attack will end; report the situation to your provider and, if necessary, to the relevant authorities.
7. Review afterwards: Which addresses were targeted, which measure worked? Adjust your permanent rules accordingly.

Heavy traffic is sometimes used to mask another attack. Once the attack is over, review file changes and login records as well.

Checklist

• Your hosting provider's DDoS protection and support line are known.
• A CDN or WAF is in use; it is clear how to switch on attack mode.
• The server's real IP address is not needlessly exposed.
• Static files and public pages are cached.
• Login, form and search endpoints are rate limited.
• Forms have a honeypot field or a captcha.
• Uptime monitoring and alerts are set up.
• Who does what during an attack is written down; the channel for informing customers has been decided.

Frequently asked questions

Related guides

• Server and hosting securitySFTP/FTPS, file permissions, directory listing, error display, sensitive files and database access.
• Login and session securityPassword hashing, attempt limits, session fixation, cookie flags and authorisation checks on every request.
• Website backup and monitoringFile and database backups, restore drills, file integrity, logs and uptime monitoring.
• Website security guide: where should you start?Threat types, layered defence, priorities and a roadmap to all the security guides.