Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (3.0)  

CWE-799: Improper Control of Interaction Frequency

Weakness ID: 799
Abstraction: Class
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests.
+ Extended Description
This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.
+ Alternate Terms
Insufficient anti-automation:
The term "insufficient anti-automation" focuses primarly on non-human actors such as viruses or bots, but the scope of this CWE entry is broader.
Brute force:
Vulnerabilities that can be targeted using brute force attacks are often symptomatic of this weakness.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
+ Relevant to the view "Development Concepts" (CWE-699)
MemberOfCategoryCategory438Behavioral Problems
MemberOfCategoryCategory840Business Logic Errors
ParentOfBaseBase837Improper Enforcement of a Single, Unique Action
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Architecture and Design
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.


Class: Language-Independent (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Access Control

Technical Impact: DoS: Resource Consumption (Other); Bypass Protection Mechanism; Other

+ Demonstrative Examples

Example 1

In the following code a username and password is read from a socket and an attempt is made to authenticate the username and password. The code will continuously checked the socket for a username and password until it has been authenticated.

(bad code)
Example Language:
char username[USERNAME_SIZE];
char password[PASSWORD_SIZE];

while (isValidUser == 0) {
if (getNextMessage(socket, username, USERNAME_SIZE) > 0) {
if (getNextMessage(socket, password, PASSWORD_SIZE) > 0) {
isValidUser = AuthenticateUser(username, password);




This code does not place any restriction on the number of authentication attempts made. There should be a limit on the number of authentication attempts made to prevent brute force attacks as in the following example code.

(good code)
Example Language:
int count = 0;
while ((isValidUser == 0) && (count < MAX_ATTEMPTS)) {
if (getNextMessage(socket, username, USERNAME_SIZE) > 0) {
if (getNextMessage(socket, password, PASSWORD_SIZE) > 0) {
isValidUser = AuthenticateUser(username, password);



if (isValidUser) {

else {

+ Observed Examples
Mail server allows attackers to prevent other users from accessing mail by sending large number of rapid requests.
+ Weakness Ordinalities
(where the weakness exists independent of other weaknesses)
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
MemberOfCategoryCategory8082010 Top 25 - Weaknesses On the Cusp
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
WASC21Insufficient Anti-Automation
+ References
[REF-731] Web Application Security Consortium. "Insufficient Anti-automation". <>.
+ Content History
Submission DateSubmitterOrganization
2010-01-15CWE Content TeamMITRE
New entry to handle anti-automation as identified in WASC.
Modification DateModifierOrganization
2010-04-05CWE Content TeamMITRE
updated Demonstrative_Examples
2011-03-29CWE Content TeamMITRE
updated Observed_Examples, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples

More information is available — Please select a different filter.
Page Last Updated: January 18, 2018