A junior nurse should not be able to access every patient record in the hospital. A contractor should not be able to read internal financial reports. An employee logged in from an unrecognized device at 2AM probably should not be editing production configuration files.

Simple role-based systems handle obvious cases well. But as applications grow and access rules become more nuanced, those systems start to crack. You end up creating more and more specific roles, like finance_viewer, finance_viewer_us_only, finance_viewer_us_only_readonly, until the roles themselves become unmanageable.

Attribute-Based Access Control (ABAC) was designed to solve exactly this problem. It shifts from "what role does this user have?" to "what do we know about this user, this resource, and this situation?" and makes access decisions based on all of those factors together.

In this guide, you'll learn how ABAC works, how it evolved from earlier access control models, how policies are structured, how to implement it in code, and when to use it.

Table of Contents

• Prerequisites

• How Access Control Has Evolved

• What is Attribute-Based Access Control?

• The Four Building Blocks of ABAC

• How an ABAC Decision is Made

• How to Write ABAC Policies

• How to Implement ABAC in Code

• ABAC vs RBAC: When to Use Which

• Real-World Use Cases

• Enterprise ABAC Considerations

• Limitations and Challenges

• Conclusion

• Glossary

Prerequisites

To get the most from this article, you should have:

• A basic understanding of web authentication (logins, sessions, tokens)

• Familiarity with how users and resources relate in applications

• Some experience reading JavaScript or pseudocode

No prior knowledge of access control theory is required.

How Access Control Has Evolved

To understand why ABAC exists, it helps to understand what came before it and why each generation fell short.

Discretionary and Mandatory Access Control

Early access control models emerged from Department of Defense applications in the 1960s and 1970s. According to NIST Special Publication 800-162, these were Discretionary Access Control (DAC) and Mandatory Access Control (MAC).

In DAC, the owner of a resource decides who can access it. Think of a file on your computer where you choose who can read or edit it. In MAC, access is governed by a central authority using labels like "Classified" or "Top Secret." The system enforces these labels, not individual owners.

Both worked for their original purposes but didn't scale well to the complexity of modern networked systems.

Identity-Based Access Control and Access Control Lists

As networks grew, identity-based access control (IBAC) became common. The most familiar implementation is the Access Control List (ACL), a list of users or groups attached to a resource, specifying what each can do.

ACLs are simple and transparent, but they create a management burden as systems grow. Every new user needs to be added to every relevant list. Every permission change means hunting through lists across multiple resources. And when someone leaves the organization, you need to find and remove them everywhere.

Failure to do this consistently leads to users accumulating privileges they should no longer have.

Role-Based Access Control

Role-Based Access Control (RBAC) was a major step forward. Instead of assigning permissions directly to users, RBAC assigns them to roles. Users are then assigned roles. A hospital might have roles like nurse, doctor, admin, and billing_staff, each with different permissions.

This made administration much more manageable. Adding a new employee means assigning them appropriate roles. Removing an employee means removing their roles. Changing what nurses can do means updating the nurse role once.

RBAC became widely adopted and is still the right choice for many applications. But it has a structural weakness: as permission requirements become more granular, you have to create more specific roles. A nurse who can only see patients on their floor, only during their shift, or only for certain record types, needs a very specific role, or a combination of roles that interacts in complicated ways.

This proliferation is called "role explosion." The roles multiply until they are as difficult to manage as the individual permissions RBAC was supposed to replace.

Attribute-Based Access Control

ABAC emerged as a response to role explosion. Instead of assigning roles that bundle fixed permissions, ABAC evaluates the actual characteristics of the user, the resource, and the context at the moment of every access request.

A nurse gets access to a patient record not because they have the nurse role, but because their job title is "Nurse Practitioner," the patient is on their assigned floor, it's currently their shift, and the record type is within their scope of care. Change any of those facts, and the access decision changes accordingly.

As NIST SP 800-162 defines it, ABAC is:

"an access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions."

What is Attribute-Based Access Control?

ABAC is a logical access control model where every access decision is made by evaluating a set of rules against the current values of attributes. Nothing is pre-computed or cached in role assignments. Every time a user tries to do something, the system asks: given what we know about this user, this resource, and this moment, should this be allowed?

This makes ABAC highly precise and highly dynamic. Permissions don't accumulate over time. They don't need manual cleanup when someone's role changes. The system simply evaluates the current state of attributes every time.

The model is formally described in NIST's guide to ABAC as being capable of enforcing both Discretionary Access Control and Mandatory Access Control concepts, making it more expressive than models that only support one or the other.

Companies like Axiomatics, major government agencies, and large enterprises managing cross-organizational data sharing all rely on ABAC for its ability to scale security policies across complex environments.

The Four Building Blocks of ABAC

Every ABAC system is built from four types of information. Understanding these clearly is the key to understanding how ABAC works.

1. Subject Attributes

The subject is whoever or whatever is requesting access. This is usually a user, but it can also be a service, an application, or an automated system, what NIST calls a Non-Person Entity (NPE).

Subject attributes describe who the subject is:

user.jobTitle         = "Nurse Practitioner"
user.department       = "Cardiology"
user.clearanceLevel   = "Confidential"
user.employmentStatus = "Active"
user.location         = "Floor 3"
user.shiftActive      = true

These attributes are typically sourced from an identity provider, HR system, or user directory. They're facts about the user that can be used in policies.

2. Object Attributes (Resource Attributes)

The object is whatever the subject is trying to access. This could be a file, a database record, an API endpoint, a service, or any other protected resource.

Object attributes describe what the resource is:

record.type           = "PatientMedical"
record.floor          = "Floor 3"
record.sensitivity    = "High"
record.owner          = "Dr. Williams"
record.department     = "Cardiology"

Object attributes are typically assigned when a resource is created and updated throughout its lifecycle. They're facts about the resource that determine who should be able to access it.

3. Action Attributes

The action is what the subject is trying to do to the object. Common actions include read, write, edit, delete, copy, execute, and share.

In many ABAC implementations, the action itself has attributes:

action.type           = "read"
action.bulk           = false

Policies can restrict which actions are allowed independently of the other attributes. A user might be able to read a document but not delete it, even if all their other attributes match.

4. Environment Conditions

Environment conditions are contextual factors that don't belong to either the subject or the object, but that should influence the access decision. NIST describes these as "dynamic factors, independent of subject and object, that may be used as attributes at decision time to influence an access decision."

Examples include:

environment.time           = "14:30"
environment.dayOfWeek      = "Wednesday"
environment.userLocation   = "Corporate Office"
environment.ipAddress      = "192.168.1.10"
environment.deviceStatus   = "compliant"
environment.threatLevel    = "low"

Environment conditions are what make ABAC truly dynamic. The same user, the same resource, and the same action might be allowed during business hours on a trusted device but denied at midnight from an unknown IP address.

How an ABAC Decision is Made

When a subject tries to perform an action on an object, the ABAC system runs through a specific process:

Step 1: Collect Attributes

The system gathers current attributes for the subject, object, action, and environment. This might involve querying a user directory, reading resource metadata, and checking current time and location.

Step 2: Find Applicable Policies

The system identifies which policies apply to this particular request. A request to read a patient record might have several policies that apply: one about clinical staff access, one about after-hours access, and one about record sensitivity levels.

Step 3: Evaluate Each Policy

Each applicable policy evaluates the collected attributes and returns permit or deny.

Step 4: Reconcile Conflicts

If multiple policies apply and they conflict, the system uses predefined combining rules. Common approaches are "deny overrides" (if any policy says deny, the request is denied) or "permit overrides" (if any policy says permit, the request is permitted).

Step 5: Enforce the Decision

The system grants or denies access based on the final decision.

This process happens every time an access request is made. There's no caching of role assignments or pre-computed permission tables. The decision reflects the current state of all attributes at the moment of the request.

How to Write ABAC Policies

Policies are the logic at the heart of ABAC. They're written as conditional rules that reference attributes. A well-written policy reads like a business rule, because that's exactly what it is.

Simple Boolean Policy

The most basic form evaluates whether certain attributes match:

// Policy: Only active employees can access internal resources
function canAccessInternalResource(user) {
  return user.employmentStatus === "Active";
}

What this does: Checks a single attribute, employment status, before allowing access. Any inactive, suspended, or terminated user is denied, regardless of their roles or past access history.

Multi-Attribute Policy

Real policies typically combine multiple attributes:

// Policy: A nurse can read a patient record
// if the patient is on their assigned floor
// and during their active shift

function canReadPatientRecord(user, record, environment) {
  const isNurse = user.jobTitle === "Nurse Practitioner";
  const isAssignedFloor = user.assignedFloor === record.floor;
  const isActiveDuty = user.shiftActive === true;

  return isNurse && isAssignedFloor && isActiveDuty;
}

What this does: Combines three conditions using AND logic. All three must be true for access to be granted. Change the nurse's floor assignment, and they immediately lose access to records on the previous floor, without any manual intervention.

Environment-Aware Policy

Adding environment conditions makes policies context-sensitive:

// Policy: Users can only access sensitive financial records
// during business hours from the corporate network

function canAccessSensitiveFinancialRecord(user, record, environment) {
  const isFinanceStaff = user.department === "Finance";
  const isHighSensitivity = record.sensitivity === "High";
  
  // If this is a high-sensitivity record, apply time and location controls
  if (isHighSensitivity) {
    const currentHour = new Date(environment.timestamp).getHours();
    const isBusinessHours = currentHour >= 9 && currentHour < 17;
    const isCorporateNetwork = environment.ipRange === "corporate";

    return isFinanceStaff && isBusinessHours && isCorporateNetwork;
  }

  // Lower sensitivity records only require finance department membership
  return isFinanceStaff;
}

What this does: Applies stricter controls to higher-sensitivity resources. The same user gets access to low-sensitivity records at any time, but high-sensitivity records require them to be on the corporate network during business hours. The policy logic mirrors the actual business rule: sensitive data needs more protection.

Ownership-Based Policy

ABAC can also implement discretionary ownership rules:

// Policy: A user can edit a document
// if they own it, or if they have editor permissions
// and the document isn't locked

function canEditDocument(user, document, action) {
  const isOwner = document.ownerId === user.id;
  const hasEditorPermission = user.permissions.includes("document.edit");
  const isUnlocked = document.status !== "locked";

  return (isOwner || hasEditorPermission) && isUnlocked;
}

What this does: Combines ownership (an attribute of the relationship between user and document) with explicit permissions and resource state. An editor can't edit a locked document even if they have the edit permission. An owner can edit their own documents but not locked ones.

How to Implement ABAC in Code

Let's build a simple ABAC evaluation engine that puts these pieces together.

Step 1: Define the Attribute Structure

First, define clear data structures for your attributes:

// A user (subject) requesting access
const user = {
  id: "user-123",
  name: "Sarah Chen",
  department: "Cardiology",
  jobTitle: "Nurse Practitioner",
  clearanceLevel: 2,
  assignedFloor: "Floor 3",
  shiftActive: true,
  employmentStatus: "Active"
};

// A resource (object) being accessed
const patientRecord = {
  id: "record-456",
  type: "PatientMedical",
  floor: "Floor 3",
  sensitivity: 2,
  ownerId: "doctor-789",
  department: "Cardiology"
};

// Environment conditions
const environment = {
  timestamp: new Date().toISOString(),
  ipAddress: "10.0.1.25",
  ipRange: "corporate",
  deviceCompliant: true
};

Step 2: Write Policy Functions

Write individual policies as pure functions that take attributes and return boolean values:

// policies/patientRecord.js

// Policy 1: User must be active and clinical staff
function isClinicalStaff(user) {
  const clinicalTitles = [
    "Nurse Practitioner",
    "Physician",
    "Resident",
    "Medical Assistant"
  ];
  return (
    user.employmentStatus === "Active" &&
    clinicalTitles.includes(user.jobTitle)
  );
}

// Policy 2: Record must be within the user's assigned area
function isAssignedToRecord(user, record) {
  return (
    user.department === record.department &&
    user.assignedFloor === record.floor
  );
}

// Policy 3: User must be on active shift
function isOnActiveShift(user) {
  return user.shiftActive === true;
}

// Policy 4: High-sensitivity records require compliant devices
function meetsDeviceRequirements(record, environment) {
  if (record.sensitivity >= 3) {
    return environment.deviceCompliant === true;
  }
  return true; // No device requirement for lower sensitivity
}

What this does: Each policy is a small, focused function. This makes policies easy to test individually, easy to read, and easy to reuse across different access decisions. A policy for "is this user clinical staff" can be applied to many different resource types.

Step 3: Build an Evaluation Engine

Combine your policies into a decision engine:

// abac/engine.js

function evaluateAccess(user, resource, action, environment, policies) {
  // Collect all policy results
  const results = policies.map(policy => {
    try {
      return policy(user, resource, action, environment);
    } catch (error) {
      console.error(`Policy evaluation error: ${error.message}`);
      return false; // Fail closed: deny on error
    }
  });

  // Deny-overrides: if any policy denies, access is denied
  return results.every(result => result === true);
}

// Assemble policies for reading patient records
const readPatientRecordPolicies = [
  (user) => isClinicalStaff(user),
  (user, record) => isAssignedToRecord(user, record),
  (user) => isOnActiveShift(user),
  (user, record, action, environment) => meetsDeviceRequirements(record, environment)
];

// Make an access decision
const canRead = evaluateAccess(
  user,
  patientRecord,
  "read",
  environment,
  readPatientRecordPolicies
);

console.log(`Access ${canRead ? "granted" : "denied"}`);
// → Access granted (all conditions met)

What this does: The engine loops through each policy function, passing in the relevant attributes. If all policies return true, access is granted. If any returns false, access is denied. This is called "deny-overrides combining". The try-catch ensures that if a policy throws an error, access is denied rather than granted, following the security principle of fail-closed.

Step 4: Add Attribute Collection

In a real application, attributes come from multiple sources:

// attributes/collector.js

async function collectAttributes(userId, resourceId) {
  // Collect in parallel for performance
  const [user, resource, environment] = await Promise.all([
    fetchUserAttributes(userId),      // From identity provider or HR system
    fetchResourceAttributes(resourceId), // From resource metadata store
    collectEnvironmentConditions()    // Time, IP, device status
  ]);

  return { user, resource, environment };
}

async function fetchUserAttributes(userId) {
  // This would query your user directory, LDAP, or identity provider
  const user = await userDirectory.findById(userId);
  const shift = await shiftService.getActiveShift(userId);
  
  return {
    ...user,
    shiftActive: shift !== null,
    assignedFloor: shift?.floor || null
  };
}

async function collectEnvironmentConditions() {
  return {
    timestamp: new Date().toISOString(),
    ipAddress: request.ip,
    ipRange: await networkService.classifyIP(request.ip),
    deviceCompliant: await deviceService.checkCompliance(request.deviceId)
  };
}

What this does: Attribute collection is separated from policy evaluation. This is an important design decision: it means you can test policies with any attribute values without needing real users or resources. It also means you can swap out the source of attributes (say, moving from an on-premise directory to a cloud identity provider) without changing your policies.

Step 5: Integrate with Your API

Use the evaluation engine in your API handlers:

// middleware/abac.js

function requireAccess(action, resourceType) {
  return async (req, res, next) => {
    try {
      const { user, resource, environment } = await collectAttributes(
        req.user.id,
        req.params.id
      );

      const policies = getPoliciesFor(resourceType, action);
      const allowed = evaluateAccess(user, resource, action, environment, policies);

      if (!allowed) {
        // Log the denial for audit purposes
        auditLog.record({
          userId: req.user.id,
          resourceId: req.params.id,
          action,
          decision: "denied",
          timestamp: new Date()
        });

        return res.status(403).json({ error: "Access denied" });
      }

      next();
    } catch (error) {
      // Fail closed: deny access on unexpected errors
      return res.status(403).json({ error: "Access denied" });
    }
  };
}

// Use in route definitions
app.get(
  "/patient-records/:id",
  authenticate(),                               // First verify identity
  requireAccess("read", "patientRecord"),       // Then evaluate ABAC
  patientRecordController.getById               // Then handle the request
);

What this does: The ABAC check lives in middleware that runs between authentication and the route handler. Authentication establishes who the user is. ABAC decides whether that user can do what they're trying to do. This separation keeps authorization logic out of your business logic.

ABAC vs RBAC: When to Use Which

RBAC isn't obsolete. It's genuinely the right choice for many applications. The question is which model fits your specific access requirements.

RBAC Strengths

RBAC is simple to understand, simple to implement, and simple to audit. If you can describe your access requirements as a list of roles with fixed permissions, RBAC works well. Most SaaS applications start with RBAC and it serves them fine for years.

A typical RBAC check looks like:

// Simple RBAC: does the user have the required role?
function canAccess(user, requiredRole) {
  return user.roles.includes(requiredRole);
}

It's fast, clear, and easy to debug. When something goes wrong, you check which roles the user has and which roles the resource requires.

Where RBAC Breaks Down

RBAC struggles when permissions need to depend on factors that aren't captured by a role. If you need to express "finance managers can view financial records, but only for their own region, and only during business hours," you're outside what a role alone can express cleanly.

You either need an extremely specific role (finance_manager_us_east_business_hours) that creates the role explosion problem, or you add conditional logic to your application code that effectively recreates ABAC, just in a less organized way.

RBAC vs ABAC Comparison

Combining Both Models

RBAC and ABAC work well together. A common pattern is to use RBAC for coarse-grained access control (which sections of your application can this user see?) and ABAC for fine-grained control within those sections (which specific records can they access?).

For example, a role might grant access to the patient records section of a hospital system. Within that section, ABAC policies determine which specific records a user can view or edit based on their department, assigned floor, and active shift.

Real-World Use Cases

Healthcare Records Management

Healthcare is one of the clearest examples of why ABAC matters. Patient privacy regulations require precise access control, and patient care requires that the right staff can access records quickly when they need them.

An ABAC policy in a hospital might allow a nurse to view a patient's record only when:

1. the patient is currently admitted to the nurse's assigned floor,

2. the nurse is on an active shift,

3. the access occurs from within the hospital network,

4. and the record type is within the nurse's care scope.

According to WorkOS's ABAC analysis, in emergency situations ABAC systems can automatically expand access rights. For example, an ER doctor automatically gains broader access to patient records to provide immediate care, with this access being time-bound and closely monitored.

All of these rules would require dozens of roles in an RBAC system, and those roles would still struggle to handle the emergency access scenario dynamically.

Corporate Data Access

Large enterprises typically have employees across departments, roles, locations, and clearance levels who need different views of the same underlying data. A document might be accessible to finance managers in the US region during business hours, accessible to executives globally at any time, but inaccessible to contractors entirely.

ABAC expresses all of these rules in policies. As employees change departments, go on leave, or change roles, their attributes update in the identity system and their access changes automatically, with no manual ACL updates required.

Government and Classified Information

The US federal government's adoption of ABAC is described in NIST SP 800-162, which was developed to address the Federal Identity, Credential, and Access Management (FICAM) requirements. Federal agencies deal with information shared across organizational boundaries, with varying classification levels and need-to-know requirements.

ABAC allows an analyst in one agency to access information from another agency without requiring the second agency to pre-provision an account for them. The analyst's clearance attributes, organizational affiliation, and project assignments are evaluated against the resource's classification and access rules at the time of the request.

Multi-Tenant SaaS Applications

SaaS applications that serve multiple organizations need to ensure strict data isolation between tenants while supporting complex permission structures within each tenant.

ABAC handles this naturally. A resource attribute like record.tenantId is evaluated against the user attribute user.tenantId, and no cross-tenant access is possible through policy. Within a tenant, ABAC supports as much complexity as the tenant's policies require.

Enterprise ABAC Considerations

Deploying ABAC at enterprise scale introduces several challenges that don't exist in smaller implementations.

Policy Administration

Policies need to be authored, reviewed, tested, and deployed. According to NIST SP 800-162, this requires a Policy Administration Point (PAP), an interface for creating and managing policies. Without proper tooling, policies become difficult to audit and maintain.

In practice, this means treating policies like code: version control, code review, and automated testing.

Attribute Quality and Freshness

ABAC is only as good as the attributes it evaluates. If user attributes are stale, for example, for a user who changed departments but whose directory entry hasn't been updated, the access decisions will be wrong.

NIST warns that "attributes that are not refreshed as often will ultimately be less secure than attributes that are refreshed in real time." Building reliable attribute pipelines from authoritative sources is often the hardest part of ABAC deployment.

Performance

Evaluating policies on every request has a performance cost. Each evaluation may require fetching attributes from multiple sources. To manage this, many implementations use attribute caching, but caching introduces the staleness problem described above.

The solution is to cache with appropriate TTLs (time-to-live values) based on how quickly each attribute type can change. A user's department changes rarely and can be cached for hours. A user's active shift status might change every 8 hours and needs a shorter cache. Real-time location might not be cacheable at all.

Audit Logging

Because ABAC makes decisions dynamically, auditing requires logging the attributes used in each decision, not just the decision itself. A log entry that says "access denied" is only useful if it also captures why access was denied and which attributes failed to satisfy which policies.

NIST notes that without tracking attribute values at decision time, accountability requirements can't be met.

Limitations and Challenges

ABAC is powerful, but it's not the right solution for every access control problem. It's worth being honest about its limitations before committing to an implementation.

Complexity: According to NIST SP 800-162, "an ABAC system is more complicated, and therefore more costly to implement and maintain, than simpler access control systems." The flexibility that makes ABAC powerful also makes it harder to reason about. A user asking "why can't I access this?" requires examining all the attributes that were evaluated and which conditions weren't met.

Policy Conflicts: In complex systems with many policies, conflicts between policies can occur. Two policies might individually seem correct but together produce unexpected results. Resolving these conflicts requires clear precedence rules and careful policy design.

Attribute Management Overhead: Maintaining accurate attributes across large user populations requires investment in identity infrastructure. Attributes from different systems need to be normalized, validated, and kept synchronized. As NIST describes it, organizations need an entire attribute management infrastructure, not just a policy engine.

Testing is Hard: Because access depends on the combination of potentially dozens of attributes, testing edge cases comprehensively requires thought. A policy that works correctly for typical cases might behave unexpectedly for unusual attribute combinations.

Not Always Worth the Investment: For applications with straightforward access requirements, ABAC introduces unnecessary complexity. If your needs can be expressed cleanly as a set of roles with fixed permissions, RBAC is the better choice.

Conclusion

Attribute-Based Access Control represents a genuine evolution in how applications manage authorization. Rather than maintaining ever-growing lists of roles and permissions, ABAC evaluates the actual characteristics of users, resources, and context at the moment of every request.

It solves the role explosion problem that plagues complex RBAC implementations. It enables access rules that reflect real business policies rather than technical approximations of them. It handles dynamic scenarios, emergencies, time-based restrictions, and cross-organizational access that are difficult or impossible to express with static roles.

But ABAC isn't universally better. It's more complex to build, harder to debug, and requires investment in attribute management infrastructure that simpler models don't need. Many applications are well-served by RBAC, and some use RBAC and ABAC together.

The right question isn't "should I use ABAC?" It's "are my access requirements complex enough that the investment in ABAC pays off?" If your access rules change frequently, depend on resource or environment context, or need to scale across organizational boundaries, ABAC is worth serious consideration.

Start by identifying where your current access control model is breaking down. If you're creating roles to represent every edge case, if you're writing conditional logic inside route handlers that checks specific attribute values, or if users are accumulating permissions they should no longer have, those are signals that a more expressive model would help.

ABAC is the tool for when roles aren't enough.

Glossary

ABAC (Attribute-Based Access Control): An access control method where authorization decisions are made by evaluating policies against the attributes of subjects, objects, actions, and environment conditions. Defined by NIST as the approach where "subject requests to perform operations on objects are granted or denied based on assigned attributes."

Subject: The entity requesting access to a resource. Usually a human user, but can also be a service, automated process, or device. Also called the "requestor."

Object: The resource being protected, such as a file, database record, API endpoint, service, or any system resource whose access is managed by the ABAC system.

Attribute: A characteristic of a subject, object, action, or environment expressed as a name-value pair. For example, user.department = "Finance" or record.sensitivity = "High".

Subject Attributes: Properties describing the user or service making the request, such as job title, department, clearance level, or current location.

Object Attributes: Properties describing the resource being accessed, such as its type, owner, sensitivity level, or department.

Environment Conditions: Contextual factors independent of both subject and object that influence access decisions. Examples include time of day, day of week, IP address, device compliance status, or current threat level.

Policy: A rule or set of rules that evaluates attribute values to determine whether a specific access request should be permitted or denied. ABAC policies are typically written as logical conditions.

Policy Decision Point (PDP): The component of an ABAC system that evaluates policies and attributes to compute an access decision.

Policy Enforcement Point (PEP): The component that intercepts access requests and enforces the decisions made by the PDP.

Policy Information Point (PIP): The component that retrieves attribute values needed by the PDP to make decisions.

Policy Administration Point (PAP): The component that provides an interface for creating, testing, and managing policies.

RBAC (Role-Based Access Control): An access control model that assigns permissions to roles and users to roles. Simpler than ABAC but less expressive for complex, dynamic access requirements.

Role Explosion: The proliferation of increasingly specific roles in an RBAC system as access requirements become more granular, eventually making the roles as difficult to manage as individual permissions.

DAC (Discretionary Access Control): An access control model where resource owners control who can access their resources. Common in file systems.

MAC (Mandatory Access Control): An access control model where access is governed by a central authority using classification labels, independent of resource owner preferences.

ACL (Access Control List): A list associated with a resource that specifies which users or groups have which permissions. Common in identity-based access control systems.

Non-Person Entity (NPE): A subject that is not a human user, such as an automated service, application, or network device, that can request access to resources.

Attribute Caching: Storing previously retrieved attribute values to improve performance, at the cost of potentially using stale data for access decisions.

Deny-Overrides Combining: A policy combining rule where if any applicable policy returns deny, the overall decision is deny, regardless of other policies that may return permit.

Fail-Closed: A security design principle where unexpected errors or missing information result in access being denied rather than granted, reducing the risk of unauthorized access.

Source: Definitions adapted from NIST Special Publication 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations, January 2014 (with updates through August 2019).

So if you’re an iOS developer, you should also learn to prioritize security at every stage of app development.

Swift, Apple’s modern programming language, offers a wealth of tools and frameworks that simplify development while enhancing security, but only when used correctly.

This article explores 10 common security pitfalls in Swift-based iOS apps and offers practical strategies to mitigate them.

Prerequisites

Before diving in, you’ll need:

• Working knowledge of Swift and iOS development.

• Access to Xcode.

• Basic understanding of how iOS apps communicate with servers.

• Familiarity with Terminal/command line basics.

The code examples are practical and explained step-by-step, making them accessible to junior developers while still offering value to experienced ones looking to strengthen their app's security.

What we’ll cover:

• What are the Most Prevalent Security Traps in Swift iOS Applications?
  • 1. Insecure Data Storage
  • 2. Weak Network Communication
  • 3. Improper Input Validation
  • 4. Hardcoding Secrets
  • 5. Insufficient Authentication and Authorization
  • 6. Insecure Logging and Error Handling
  • 7. Ignoring Code Obfuscation and Reverse Engineering
  • 8. Insecure Third-Party Libraries
  • 9. Insufficient Biometric and Multi-Factor Authentication
  • 10. Disregarding Periodic Security Testing

What are the Most Prevalent Security Traps in Swift iOS Applications?

Swift and iOS offer robust security features, but mistakes still happen. Following are the most common traps and how to fix them:

1. Insecure Data Storage

Among the most common mistakes developers make is having sensitive data stored insecurely. Passwords, tokens, or even individual user data can be left by accident in UserDefaults or local storage in unencrypted form.

While UserDefaults is convenient for small amounts of data, it is not secure for sensitive data as it is so easily accessible to attackers if the device is compromised.

How to Fix:

Use the Keychain Services API to securely store sensitive data. Keychain encrypts data and binds it to the device so that it can't be accessed by other unauthorized applications or users.

You can securely store credentials using libraries in Swift such as KeychainAccess or the built-in SecItemAdd and SecItemCopyMatching functions.

For example, this how you can store a user password in Keychain so as to ensure sensitive data is stored securely:

do {

try keychain.set("userPassword123", key: "userPassword")

} catch {

    print("Error saving to Keychain: \(error)")

}

Behind the scenes, here’s what happens when you call keychain.set("userPassword123", key: "userPassword") inside a KeychainManager class that uses Apple’s native Security framework for storage:

import Security

class KeychainManager {
 func set(_ value: String, key: String) throws {
     // 1. Convert string to Data
     guard let data = value.data(using: .utf8) else {
         throw NSError(domain: "KeychainManager", code: -1)
     }

     // 2. Build the query dictionary
     let query: [String: Any] = [
         // Store as password
         kSecClass as String: kSecClassGenericPassword,
         // Your app's bundle identifier
         kSecAttrService as String: "com.yourapp.keychain",
         // "userPassword"
         kSecAttrAccount as String: key,
         // "userPassword123" encrypted
         kSecValueData as String: data,
         kSecAttrAccessible as String: kSecAttrAccessibleAfterFirstUnlock
     ]
     // 3. Save to keychain (iOS encrypts it automatically)
     let status = SecItemAdd(query as CFDictionary, nil)
     // 4. Check if successful
     guard status == errSecSuccess else {
         throw NSError(domain: "KeychainManager", code: Int(status))
     }
 }
}

When this function runs, iOS converts the string value, such as "userPassword123", into encrypted binary data and stores it securely in the device’s Keychain database. The entry is saved under the provided key (for example, "userPassword"), and only your app can access it.

Behind the scenes, the Keychain leverages strong security features, including hardware-backed encryption using device-specific keys, optional biometric protection through Face ID or Touch ID, and app-level isolation to ensure that no other app can read or modify your stored credentials.

2. Weak Network Communication

Transmitting sensitive data over the network is another area prone to vulnerabilities. Using unencrypted HTTP connections exposes your app to man-in-the-middle (MITM) attacks, allowing attackers to intercept and modify data in transit.

The Problem: When data travels between your app and server over an insecure connection, attackers on the same network (like public Wi-Fi) can:

• Read sensitive information (passwords, personal data, payment details)

• Modify requests and responses

• Impersonate your legitimate server

How to Fix:

1. Always Use HTTPS
HTTPS encrypts all data in transit, making it unreadable to attackers. iOS's App Transport Security (ATS) enforces this by blocking insecure HTTP connections by default:

// ❌ INSECURE - HTTP connection (blocked by ATS by default)
let url = URL(string: "http://api.example.com/login")

// ✅ SECURE - HTTPS connection
let url = URL(string: "https://api.example.com/login")

You’ll want to avoid adding ATS exceptions to your Info.plist unless absolutely necessary. If a third-party API only supports HTTP, contact them to upgrade or find a more secure alternative.

2. Implement Certificate Pinning (Advanced Protection)

Even with HTTPS, your app could still be vulnerable to sophisticated MITM attacks. An attacker could install a fraudulent certificate on a user's device (through malware or social engineering), for example, and intercept HTTPS traffic that appears valid. The attacker's fake certificate would be trusted by the device, allowing them to decrypt and read "secure" communications.

Certificate pinning solves this by making your app trust only your specific server's certificate, rejecting all others – even if they're otherwise valid.

How Certificate Pinning Works:

Your app stores the expected certificate (or its public key hash) and validates it during each connection:

class SecureNetworkManager: NSObject, URLSessionDelegate {

    // Store your server's certificate hash
    // Get this by running: openssl x509 -in certificate.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64
    private let expectedPublicKeyHash = "YOUR_CERTIFICATE_HASH_HERE"

    func urlSession(
        _ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void
    ) {
        // Step 1: Check if this is a server trust challenge (certificate validation)
        guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust,
              let serverTrust = challenge.protectionSpace.serverTrust
        else {
            // Not a certificate challenge; use default handling
            completionHandler(.performDefaultHandling, nil)
            return
        }

        // Step 2: Validate that the server's certificate matches our pinned certificate
        if isValidServerTrust(serverTrust) {
            // Certificate matches - proceed with the connection
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            // Certificate doesn't match - reject the connection to prevent MITM attack
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }

    // Validates the server's certificate against our pinned hash
    private func isValidServerTrust(_ serverTrust: SecTrust) -> Bool {
        // Extract the server's certificate
        guard let serverCertificate = SecTrustGetCertificateAtIndex(serverTrust, 0) else {
            return false
        }

        // Get the public key from the certificate
        let serverPublicKey = SecCertificateCopyKey(serverCertificate)
        guard let publicKey = serverPublicKey else {
            return false
        }

        // Convert the public key to data and hash it
        var error: Unmanaged<CFError>?
        guard let publicKeyData = SecKeyCopyExternalRepresentation(publicKey, &error) as Data? else {
            return false
        }

        // Hash the public key using SHA-256
        let publicKeyHash = SHA256.hash(data: publicKeyData)
        let publicKeyHashString = Data(publicKeyHash).base64EncodedString()

        // Compare with our expected hash
        return publicKeyHashString == expectedPublicKeyHash
    }
}

What this code does, step-by-step:

1. urlSession(_:didReceive:completionHandler:) – This method is called whenever your app makes an HTTPS connection. iOS asks: "Should I trust this server's certificate?"

2. Check authentication method – We verify this is a server trust challenge (certificate validation), not some other type of authentication.

3. Validate the certificate – We call isValidServerTrust(), which:

   • Extracts the server's certificate from the connection

   • Gets the public key from that certificate

   • Hashes the public key using SHA-256

   • Compares the hash to our stored, expected hash

4. Make a decision:

• If hashes match, then the server is legitimate. Proceed with .useCredential.

• If hashes don't match, we have a potential MITM attack. Cancel with .cancelAuthenticationChallenge.

So how does this prevent MITM attacks? Even if an attacker installs a fraudulent certificate on the user's device and intercepts traffic, their certificate's hash won't match your pinned hash. Your app will reject the connection, preventing the attacker from decrypting your traffic.

3. Additional Protection: Recommend a VPN on Public Wi-Fi

You can also recommend that users connect through a VPN when on public Wi-Fi for an added layer of security, and provide guidance on how to use a VPN effectively to keep their data safe.

For developers, maintaining strong app security also depends on having a well-optimized system, learning how to speed up a slow Mac can help ensure smoother builds, faster testing, and a more secure overall development workflow.

3. Improper Input Validation

Some developers neglect correct input validation, leading to a number of vulnerabilities including SQL injection, remote code execution, and data corruption.

While Swift has strong typing support, some developers don’t sanitize user input or API responses. Incorporating real-time API email validation ensures that users provide legitimate, properly formatted email addresses before they are stored or processed, reducing both security risks and data quality issues.

How to Fix:

Input validation is your first line of defense against malicious data. Here's how to protect your iOS applications:

1. Validate User Input with Patterns

Always validate user input using regular expressions or predefined patterns before processing. For example, when accepting email addresses:

func isValidEmail(_ email: String) -> Bool {
    let emailRegex = "[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,64}"
    let emailPredicate = NSPredicate(format: "SELF MATCHES %@", emailRegex)
    return emailPredicate.evaluate(with: email)
}

// Only accept properly formatted data
guard isValidEmail(userEmail) else {
    // Reject invalid input
    return
}

This ensures that only properly formatted data is accepted, preventing malformed or malicious input from entering your system.

2. Sanitize API Responses

Never trust external data. Always validate and sanitize API responses before using them:

if let userAge = apiResponse["age"] as? Int,
   userAge >= 0 && userAge <= 150 {
    // Safe to use
    user.age = userAge
} else {
    // Handle invalid data appropriately
    throw ValidationError.invalidAge
}

3. Use Parameterized Queries (Most Critical)

The most dangerous mistake is building database queries through string concatenation. Consider this vulnerable code:

// ❌ NEVER DO THIS - Vulnerable to SQL Injection
let username = userInput  // Could be: "admin' OR '1'='1"
let query = "SELECT * FROM users WHERE username = '\(username)'"
database.execute(query)

If a malicious user enters admin' OR '1'='1 as their username, the query becomes:

SELECT * FROM users WHERE username = 'admin' OR '1'='1'

This would return all users in the database instead of just one, potentially exposing sensitive data. The secure solution uses parameterized queries:

// ✅ SAFE - Using parameterized queries
let query = "SELECT * FROM users WHERE username = ?"
database.execute(query, withArgumentsIn: [username])

In this approach, the ? is a placeholder that the database treats as a parameter, not as part of the SQL command. The username value is passed separately in the withArgumentsIn array.

This means that even if a user tries to inject SQL code like admin' OR '1'='1, the database will treat the entire string as a literal username to search for – not as executable SQL code. The database engine automatically escapes any special characters, completely eliminating the risk of SQL injection.

By separating the query structure from the data, parameterized queries ensure that user input can never alter the intended logic of your SQL statements.

4. Hardcoding Secrets

API keys, credentials, or private tokens hard-coded in the source code is another serious security mistake. Attackers can extract such secrets from compiled binaries using reverse-engineering tools, especially for apps released to the public.

Once exposed, these credentials can be used to access your backend services, potentially leading to data breaches or unauthorized charges.

The Problem – Hardcoded Secrets:

// NEVER DO THIS
class APIClient {
    private let apiKey = "1234567890abcdef"
    private let secretToken = "sk_live_51H..."

    func makeRequest() {
        // These secrets are embedded in your binary
        let headers = ["Authorization": "Bearer \(apiKey)"]
    }
}

How to Fix:

Never store sensitive credentials directly in your code. Here are secure alternatives:

Solution 1: Fetch Secrets from Backend at Runtime

The most secure approach is to never store secrets on the client at all. Instead, authenticate users and let your backend make authorized API calls:

class APIClient {
    private var sessionToken: String?

    // User logs in and receives a temporary session token
    func authenticateUser(email: String, password: String) async throws {
        let response = try await backend.login(email: email, password: password)
        // Store only a temporary, user-specific session token
        self.sessionToken = response.sessionToken
    }

    // Backend handles the actual API calls with the real API key
    func fetchUserData() async throws -> UserData {
        guard let token = sessionToken else {
            throw AuthError.notAuthenticated
        }

        // Your backend receives this request, validates the session token,
        // then uses its own API keys to fetch data from third-party services
        return try await backend.getUserData(sessionToken: token)
    }
}

How this works:

Your app never knows the actual API keys. When a user needs data, your app sends a request to your own backend server with a session token. Your backend validates the token, then uses its own securely stored API keys to make the actual third-party API calls. This way, the real secrets never leave your server.

Solution 2: Environment Variables or Config Files (Development Only)

For development environments, use .xcconfig files that are excluded from version control:

// Secrets.xcconfig (add to .gitignore!)
API_KEY = your_dev_api_key_here
API_SECRET = your_dev_secret_here

// Access in your code through Info.plist
class Config {
    static let apiKey: String = {
        guard let key = Bundle.main.object(forInfoDictionaryKey: "API_KEY") as? String else {
            fatalError("API_KEY not found in configuration")
        }
        return key
    }()
}

Important: This approach is only suitable for non-production environments! Never ship production API keys with your app, even in config files.

5. Insufficient Authentication and Authorization

Relying on client-side authentication and authorization checks is risky. Attackers can cause the app to bypass these checks and access in an unauthorized way by brute forcing or tampering with the app/runtime.

How to Fix:

• Do authentication and authorization on the server side instead of the client-side.

• Use JWT (JSON Web Tokens) or OAuth 2.0 for authenticated user login.

• Token expiration and refresh logic needs to be implemented in order to minimize the likelihood of token theft.

Example: Securely sending JWT:

let request = URLRequest(url: apiURL)

request.setValue("Bearer \(jwtToken)", forHTTPHeaderField: "Authorization")

6. Insecure Logging and Error Handling

Extensive and insecure logging practices, as well as uncaught exceptions, can lead to the exposure of sensitive information including usernames, passwords, and API keys.

How to Fix:

• Log sensitive information carefully.

• Implement controlled error management and provide the minimum amount of information in user-presented messages.

• Implement secure logging libraries that mask or encrypt personal data.

do {
    try someRiskyOperation()
} catch {
    // Log error securely
    Logger.log("Operation failed: \(error.localizedDescription)")
}

7. Ignoring Code Obfuscation and Reverse Engineering

Swift binaries can be reverse-engineered to expose sensitive business logic, algorithms, or hidden secrets. Attackers use tools like Hopper Disassembler, class-dump, or IDA Pro to decompile your app and analyze how it works internally. This risk is often underestimated, especially for smaller apps, but any app can be a target.

This means that when you compile a Swift app, the resulting binary contains:

• Class names and method signatures

• String literals (URLs, error messages, keys)

• The structure of your code logic

• Algorithm implementations

An attacker can extract this information and use it to understand your app's authentication flow and bypass it, copy your proprietary algorithms, find hardcoded API endpoints or keys you thought were "hidden", discover premium features to unlock without paying, and so on.

Why It's Bad – Real Example:

Let's imagine you have a premium feature check in your app:

class FeatureManager {
    func isPremiumUser() -> Bool {
        // Check if user has premium access
        let hasSubscription = UserDefaults.standard.bool(forKey: "premium_unlocked")
        return hasSubscription
    }

    func unlockPremiumFeature() {
        guard isPremiumUser() else {
            showPaywall()
            return
        }
        // Show premium content
        showPremiumContent()
    }
}

An attacker could reverse-engineer your app and discover that the method isPremiumUser() controls access, and that it simply checks a UserDefaults key called premium_unlocked. They would then know that they could use runtime manipulation tools to set this value to true, bypassing your paywall entirely.

How to Fix:

1. Use Swift Compiler Optimizations

Enable optimization flags that strip debugging symbols and make the binary harder to read:

// In your build settings:
// - Set "Optimization Level" to "-O" (or -Osize) for release builds
// - Enable "Strip Debug Symbols During Copy" = YES
// - Set "Strip Style" to "All Symbols"

This removes function names and makes the compiled code less readable – though class/method names remain partially visible.

2. Use Symbol Obfuscation Tools

Tools like SwiftShield can rename your classes, methods, and properties to meaningless names:

// Before obfuscation (readable to attackers):
class FeatureManager {
    func isPremiumUser() -> Bool { ... }
}

// After obfuscation (harder to understand):
class a7f3b2 {
    func x9k2m() -> Bool { ... }
}

While this doesn't prevent reverse engineering, it makes it significantly harder for attackers to understand what the code does.

3. Move Sensitive Logic to the Server (Best Practice)

Instead of checking premium status locally, verify it server-side:

// ✅ Secure approach - Server validates everything
class FeatureManager {
    func unlockPremiumFeature() async {
        do {
            // Server checks if user truly has premium access
            let hasAccess = try await backend.verifyPremiumAccess(userId: currentUserId)

            if hasAccess {
                showPremiumContent()
            } else {
                showPaywall()
            }
        } catch {
            // Handle error
            showPaywall()
        }
    }
}

How this works:

Your backend maintains the source of truth about premium access. Even if an attacker reverse-engineers your app and tries to bypass the check, the server will reject unauthorized requests. The app becomes just a UI layer, while all critical decisions happen server-side – where attackers can't manipulate them.

The key principle is to assume your app code is public: never rely on client-side checks for security-critical operations like payments, access control, or authentication. Use obfuscation to make reverse engineering harder, but ultimately move sensitive logic to your secure backend

8. Insecure Third-Party Libraries

Third-party libraries are at risk if they are hacked or outdated. Developers might inadvertently prioritize app functionality over potential security risks from dependencies, and ETL tools can further help by streamlining the monitoring and processing of dependency-related data to identify vulnerabilities more efficiently.

On a broader scale, implementing strong data center security practices ensures that even if third-party components introduce risks, the underlying infrastructure remains resilient against attacks.

How to Fix:

• Use only high-quality, well-maintained libraries.

• Update dependencies and monitor CVEs (Common Vulnerabilities and Exposures).

• Audit library code if it handles sensitive data.

9. Insufficient Biometric and Multi-Factor Authentication

Most applications rely on passwords alone, which are vulnerable to being hacked. Enabling biometrics like Face ID or Touch ID enhances security for users.

How to Fix:

• Tie LocalAuthentication framework for biometric authentication.

• Combine biometrics with server-based authentication for multifactor authentication (MFA).

import LocalAuthentication

let context = LAContext()

var error: NSError?

if context.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &error) {

    context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics,

                        localizedReason: "Access your account") { success, authError in

        DispatchQueue.main.async {

         if success {

                // Proceed securely

         } else {

                // Handle failure (authError may contain the reason)

                print("Authentication failed: \(authError?.localizedDescription ?? "Unknown error")")

         }

     }

}

} else {

// Biometrics not available, check error for details

    print("Biometrics unavailable: \(error?.localizedDescription ?? "Unknown error")")

}

10. Disregarding Periodic Security Testing

Apps, despite following best practices during development, often contain unexplored vulnerabilities that emerge from complex interactions, third-party dependencies, or newly discovered attack vectors. Regular security testing is absolutely essential to discover these vulnerabilities before attackers exploit them.

Security testing should happen at multiple stages, using accessible tools and practices:

1. Automated security scans: Run automatically with every build to catch common issues.

2. Self-conducted code audits: Regular security-focused reviews of your own code using established guidelines.

3. Vulnerability scanning tools: Use free tools like MobSF to analyze your app for security flaws.

4. Dependency audits: Checking third-party libraries for known security vulnerabilities.

How to Fix:

1. Implement Automated Security Scans in CI/CD

Integrate security scanning tools into your continuous integration pipeline so every code change is automatically checked:

# Example: GitHub Actions workflow for automated security scanning
name: Security Scan

on: [push, pull_request]

jobs:
  security-scan:
    runs-on: macos-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Run MobSF Security Scan
        run: |
          # Mobile Security Framework - scans for common vulnerabilities
          docker run -v $(pwd):/app opensecurity/mobile-security-framework-mobsf

      - name: Dependency Vulnerability Check
        run: |
          # Check CocoaPods/SPM dependencies for known CVEs
          brew install dependency-check
          dependency-check --scan ./Podfile.lock --format JSON

      - name: Secret Detection
        run: |
          # Detect accidentally committed secrets
          brew install truffleHog
          truffleHog filesystem . --json

      - name: Fail build on critical issues
        run: |
          if grep -q "CRITICAL" security-report.json; then
            echo "Critical security issues found!"
            exit 1
          fi

Automated scans check for:

• Hardcoded API keys, tokens, or passwords

• Insecure network configurations (allowing HTTP instead of HTTPS)

• Weak cryptographic algorithms

• Known vulnerabilities in third-party libraries

• Improper SSL/TLS certificate validation

• Insecure data storage (storing sensitive data in UserDefaults)

• Excessive app permissions

Example output from an automated scan:

Security Scan Results:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[CRITICAL] Hardcoded API Key Found
  File: APIClient.swift:15
  Issue: API key "sk_live_abc123..." detected in source code

[HIGH] Insecure HTTP Connection
  File: NetworkManager.swift:42
  Issue: App allows cleartext HTTP traffic to api.example.com
  Fix: Enforce HTTPS or add exception to Info.plist if required

[MEDIUM] Weak Encryption Algorithm
  File: DataEncryption.swift:28
  Issue: Using MD5 for hashing (cryptographically broken)
  Fix: Use SHA-256 or better

[LOW] Outdated Dependency
  Library: Alamofire 4.2.0
  Issue: Known vulnerability CVE-2021-12345
  Fix: Update to version 5.6.0 or later
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Build Failed: 2 critical issues must be fixed before deployment

2. Use MobSF (Mobile Security Framework) for Vulnerability Analysis

MobSF is a free, automated tool that analyzes your iOS app for security issues:

# Install and run MobSF locally
docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf

# Upload your .ipa file through the web interface at localhost:8000
# MobSF will analyze and provide a detailed security report

What MobSF checks:

• Binary analysis for hardcoded secrets

• Insecure data storage patterns

• Weak cryptographic implementations

• Insecure network connections

• Code quality and security best practices

• Compliance with security standards

3. Conduct Regular Code Audits Using OWASP MSTG

Use the OWASP Mobile Security Testing Guide as a checklist to audit your own code:

// Example: Following OWASP MSTG recommendations for secure storage
class SecureStorage {
    // ❌ Insecure - UserDefaults is not encrypted
    func saveTokenInsecurely(_ token: String) {
        UserDefaults.standard.set(token, forKey: "authToken")
    }

    // ✅ Secure - Using Keychain as OWASP recommends
    func saveTokenSecurely(_ token: String) throws {
        let data = token.data(using: .utf8)!
        let query: [String: Any] = [
            kSecClass as String: kSecClassGenericPassword,
            kSecAttrAccount as String: "authToken",
            kSecValueData as String: data,
            kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly
        ]

        SecItemDelete(query as CFDictionary)
        let status = SecItemAdd(query as CFDictionary, nil)

        guard status == errSecSuccess else {
            throw StorageError.saveFailed
        }
    }
}

OWASP MSTG Checklist for Self-Audit:

• [ ] Are all sensitive data encrypted at rest?

• [ ] Is HTTPS enforced for all network calls?

• [ ] Are certificates properly validated?

• [ ] Is sensitive data excluded from logs?

• [ ] Are API keys and secrets not hardcoded?

• [ ] Is user input validated and sanitized?

• [ ] Are authentication tokens stored securely in Keychain?

4. Automated Dependency Scanning

Monitor your dependencies continuously for newly discovered vulnerabilities:

# For CocoaPods projects
gem install cocoapods-audit
pod audit

# For Swift Package Manager
# Use GitHub Dependabot (free for public repos) or
brew install swift-outdated
swift-outdated

And set up automated alerts with these tools:

• GitHub Dependabot: Automatically creates PRs when vulnerable dependencies are detected (free)

• Snyk: Free tier available for open-source projects

• OWASP Dependency-Check: Free command-line tool

Conclusion

Developing secure iOS apps using Swift is all about forward-thinking. You should do all you can to avoid these common errors, like insecure storage of data, poor network communication, hard-coded secrets, or poor authentication.

Using Keychain for confidential information, requiring HTTPS, input validation, and multifactor authentication are all steps that decrease risk.

Regular testing for security vulnerabilities and limiting third-party library use can also further enhance your app's security.

Security is a continuous responsibility. Swift provides tools, but the developers need to apply those tools carefully. Security being tackled right from the start protects users' information, creates trust, and protects the reputation of the application.

The internet holds vast amounts of information. Much of this information is accessible through Google.

But did you know you can use Google in ways beyond simple searches? There’s a method called “Google Dorking” that lets you do this.

Google Dorking helps you find hidden or overlooked data on websites. It uses advanced search operators to locate hidden files, sensitive data, and more.

Google Dorking allows us to be very specific with our searches. Instead of just typing in regular keywords, we combine them with operators. These operators help Google narrow down its search results.

Before we dive in, a word of caution. While Google Dorking can be a powerful tool for research or cybersecurity testing, it also carries some risks. Using it for unauthorized access to secure information is illegal. So use it safely and correctly!

Now let’s learn how to “dork” Google.

Google Dorking Operators

Here’s a list of every common Google Dorking operator along with its purpose.

Site

Restricts search results to a specific domain or website. Example: site:example.com will show results only from that site.

InTitle

Searches for pages with a specific word or phrase in the page title. Example: intitle:login will find pages with "login" in the title.

InURL

The inurl operator is used to find specific words within the URL structure of web pages. It can help locate pages with particular keywords embedded in their web address.

For example, using inurl:login with other terms like inurl:customer or inurl:secure can reveal login pages for different sites.

An example of its use is inurl:admin. This displays URLs containing “admin,” often leading to administrative or management pages.

For more advanced searches, inurl:pho?id= can be useful to identify sites that might be vulnerable to SQL injection. URLs structured this way often include database query strings.

FileType

The filetype operator enables users to search for documents with a specific file extension. This includes extensions like PDF, DOC, or XLS.

The filetype operator makes it helpful for locating publicly accessible reports, presentations, and documents. For instance, filetype:pdf financial report finds PDF files related to financial reporting.

Combining filetype with certain keywords allows for more targeted searches. For example, searching filetype:xlsx budget could find Excel files related to budget details.

filetype:docx confidential might reveal DOCX documents containing potentially sensitive terms like “confidential,” leading to internal-use files that may be accessible publicly.

Cache

Shows Google’s cached version of a webpage, even if it’s been removed. Example: cache:example.com shows the cached version of that page.

AllInText

Searches for pages that contain all the specified words in the body text. Example: allintext:"username password" will return pages with both words in the text.

AllInTitle

Searches for pages with all specified words in the title. Example: allintitle:login admin finds pages with both words in the title.

AllInUrl

Searches for pages with multiple specified words in the URL. Example: allinurl:admin login finds URLs that contain both "admin" and "login."

InAnchor

Finds pages with specific text in anchor links (the clickable text of a link). Example: inanchor:"click here" finds links where the clickable text is "click here."

Before and After

Finds pages published before or after a specific date. Example: before:2020 will find pages published before 2020. after:2020 will find pages published after 2020.

OR

Combines two search terms and returns results containing either of them. Example: admin OR login shows pages with either "admin" or "login."

Minus (-)

Excludes specific words from the search results. Example: admin -login shows pages with “admin” but without “login.”

Asterisk (*)

Acts as a wildcard to substitute any word or phrase. Example: "admin * login" will find pages with any word between "admin" and "login."

InText

Searches for specific words in the main body of the page, not just titles or URLs. Example: intext:"confidential" finds pages where "confidential" appears in the content.

Location

Restricts results to a specific geographical location. Example: location:USA shows results focused on the USA.

How to Protect Yourself from Google Dorking

If you own a website or manage sensitive information online, understanding Google Dorking can help you secure your data. Here are some steps you can take to protect yourself:

1. Use Robots.txt Files The robots.txt file on a website tells search engines what content they shouldn’t index. Make sure that sensitive web pages or files are protected from being indexed by Google.

2. Use Password Protection If certain parts of your website are sensitive, use password protection. Google can’t access password-protected content, so it won’t show up in search results.

3. Avoid Storing Sensitive Files Publicly Do not store sensitive information like database backups, configuration files, or email lists on publicly accessible parts of your server.

4. Regularly Check for Exposed Information Use your own Google Dorking searches to see if sensitive files are showing up on Google. This can help you catch and secure information before anyone else finds it.

5. Use Web Vulnerability Scanners Tools like OWASP ZAP or Burp Suite can help you scan your own site for exposed data. These tools may catch things that you might overlook manually.

Conclusion

Google Dorking can be both helpful and dangerous, depending on how you use it. On one hand, it lets you uncover hidden information and refine your search skills. On the other, it can expose sensitive data if used irresponsibly.

Understanding the techniques of Google Dorking can make you a better internet user and help you secure your own data.

To learn how to hack machines in the real world, join our private community Hacker's Hub.

The act of application security is a shared responsibility amongst the client and server developers and negligence of one’s role can be disastrous. Statistics show that data breaches in 2023 resulted in exposure of over 8 million data records worldwide.

In this article, I'll be highlighting key areas of API security, which involves data validation. This concept is quite crucial in helping you protect your API from web attacks via malicious user data. This tutorial is well-suited for all backend developers regardless of years of experience.

To be able to follow this tutorial, here are some prerequisites:

• Knowledge of Node.js
• Knowledge of npm and package installation

With that in place, let’s get started.

How Does Data Validation Work?

First of all, what is data validation? Data validation simply entails ensuring the accuracy and reliability of the data received from external sources before onward data processing.

It is a key component of web API security as it is essential for preventing the occurrence of web injection attacks, SQL attacks and NoSQL attacks. To know more about these, you can check this link.

Note that data validation is needed but not limited to the following backend operations.:

• User login and sign up
• Response query
• Updating server databases

All these can be used as avenues by mischievous black hat hackers to gain access to the server database and obtain sensitive user details or even wreak havoc by formatting the entire database.

Popular Data Validation Tools

So far, there are lot of tools that can help the programmer achieve efficient data validation in API development.

They help you avoid reinventing the wheel of using long regex code to validate data. They provide a whole lot of features, including error handling and validation customization functionalities.

Some of these tools include:
• Joi
• Zod
• Yup
• AJv
• Valibot
• Validator.js
• Superstruct

To further shed light on these tools, we'll compare some of the most popular data validation tools mentioned above.

Pros and Cons of Data Validation Tools

To further enlighten you about these JavaScript validation tools, I will be highlighting some pros and cons of three of these popular JavaScript validation tools.

Joi

Pros

• It has a strong, large user community and development support
• It has built-in capabilities to handle complex validations

Cons

• It’s syntax is quite verbose

Zod

Pros

• It is easily compatible with Typescript projects
• It has efficient error-handling capabilities

Cons

• Async validation isn’t supported.

Yup

Pros

• It mainly uses declarative syntax to set its validation tool which confers its simplicity
• It has a comparable fast performance.

Cons

• It doesn’t provide customization features
• It has limited ability to handle complex validations

For the purpose of this tutorial, we'll use Joi as our data validation tool.

Introduction to Joi

Joi is a simple and efficient JavaScript-based data validation tool that is based on the schema-type configuration.

It has built-in capabilities for validating the occurrence of data in various forms, but not limited to Booleans, strings, functions and intervals. It can also handle complex validation operations.

Additionally, it provides minimal caching functionalities. More information about the tool can be found here.

How to Set Up Joi

In this section, we'll set up Joi in our local environment. To install Joi, navigate to the code folder via the command line and run this:

npm i joi

A message confirming successful installation should be displayed. With that completed, we can demonstrate the power of Joi in validating user registration in our demo API.

Demo Project

In this project, you'll use Joi to validate the input received from the client with the intent to sign up on the server. The default code for the user sign-up function for the Node.js application can be found here.

Go on and import the installed Joi package into your code:

const Joi = require("joi");

Before writing our signup controller, we'll initialize the Joi library within the code file:

const SignUpSchema = Joi.object({});

In this project, we'll validate the email, password and username parameters received from the client.

const SignUpSchema = Joi.object({
    email: Joi.string().email({
        minDomainSegments: 2,
        tlds: {
            allow: ['com', 'net']
        }
    }),
    username: Joi.string().alphanum().min(3).max(15).required(),
    password: Joi.string().min(8).required()
});

The email parameter object ensures that the email address is a string, and the domain site is limited to .com and .net, disallowing other forms of domains.

For the username parameter, it ensures that it is a string containing both letters and numbers with a minimum character count of 3 and a maximum character count of 15. The required function ensures that these conditions must be met or the entire request won't be validated.

The password parameter ensures that the password supplied is in a string format with a minimum character count of 8, and it is also required.

To apply it to our endpoints, we include this within the controller function:

const { error, value } = SignUpSchema.validate(req.body, { abortEarly: false });
if (error) {
    res.status(400).json(error.details);
    return;
}

This function gets executed before inserting the user details into the database. The schema tries to validate the received input and then proceeds to the database if successfully validated.

The abortEarly feature is included to allow for all parameters to be assessed. All the errors will be displayed if there is any.

The above can also be replicated in the Login controller function. You can also check out the documentation for other examples of complex validation options using Joi.

The final code for the project is displayed below:

const jwt = require("jsonwebtoken");
const userSchema = require("../Schema/User");
const Joi = require("joi");
const bcrypt = require("bcrypt");
const { createNewColumn, checkRecordsExists, insertRecord } = require('../utils/sqlSchemaFunction');

const generateAccessToken = (use) => {
    return jwt.sign({ userID: use }, process.env.JWT, { expiresIn: "1d" });
}

const SignUpSchema = Joi.object({
    email: Joi.string().email({ minDomainSegments: 2, tlds: { allow: ['com', 'net'] } }),
    username: Joi.string().alphanum().min(3).max(15).required(),
    password: Joi.string().min(8).required()
});

const loginSchema = Joi.object({
    email: Joi.string().email({ minDomainSegments: 2, tlds: { allow: ['com', 'net'] } }),
    password: Joi.string().min(8).required()
});

const register = async (req, res) => {
    const email = req.body.email;
    const password = req.body.password;

    if (!email || !password) {
        res.status(400).json("Please supply the email or password");
        return; 
    }

    const { error, value } = SignUpSchema.validate(req.body, { abortEarly: false });
    if (error) {
        res.status(400).json(error.details);
        return;
    }

    const salt = await bcrypt.genSalt(10);
    const hashedPassword = await bcrypt.hash(password, salt);
    const user = {
        username: req.body.username,
        email: email,
        password: hashedPassword
    };

    try {
        const userAlreadyExists = await checkRecordsExists("users", "email", email);
        if (userAlreadyExists) {
            res.status(400).json("Email must be unique");
        } else {
            await insertRecord("users", user);
            res.status(200).json("User created successfully");
        }
    } catch (err) {
        res.status(500).json({ err: err.message });
    }
};

module.exports = { register };

API testing in Postman

Ensuring that the code followed our defined schema resulted in it being successfully executed.

Conclusion

With this, we have come to the end of the tutorial. I hope you’ve learned about data validation, various data validation tools and data validation best practices.

You can also reach out to me and check out my other articles here. Till next time, keep on coding!

And while nothing is foolproof, there is a way to at least mitigate the effects: using the noopener and noreferrer attributes. And that's what you'll learn about in this quick tutorial.

What is Tabnabbing?

Tabnabbing is a type of phishing attack that targets the inactive tabs in your browser. While you're focused on your current tab, the link to the previous one can be hijacked, and you'll be redirected from the intended site to a malicious one resembling the real thing.

Since the malicious site looks very similar to the original, the user is typically unaware that the page they're on isn't legit once they return to that tab. Because of this, the user puts in their personal information, not knowing someone's on the other side waiting to steal it.

Some ways attackers might compromise a well-known website include:

• malicious ads

• 3rd party widgets that the website has included, which were later compromised

• malicious user-generated content (like forum posts) that contain unsanitized JavaScript

A Quick Example of Tabnabbing

Think of how a website with your personal details logs you out automatically when you're inactive for too long. Since that means your attention's elsewhere, the attacker can switch out the real page for a very convincing fake.

When you go back to that tab, you wouldn't know the difference, so you log back in, and the phisher now has access to your private details.

As is the case for phishing attacks, the purpose of this action is to deceive the unsuspecting user into entering sensitive information (usually login or financial info) on the phony site.

This is, of course, a problem you'll want to avoid for your site when visitors come! You'll want to make sure people are safe when clicking any of your links, right?

So now you're going to learn how to make your corner of the internet a little bit safer—starting with learning how to open a new tab to begin with.

How to Open a Link in a New Tab in HTML

To open a link in a new tab, write out a link how you would in HTML, then just add the target attribute, setting the value to blank, like this: target="_blank":

<p>Learn to code for free at <a href ="https://www.freecodecamp.org/" target="_blank">freeCodeCamp.org!</a><p/>

On the page, it would look like this:

Learn to code for free at freeCodeCamp.org!

How to Add a Noopener/Noreferrer Attribute

Unfortunately, the more tabs you have open (who doesn't multitask on their browser?), the more susceptible you are to tabnabbing. This is because the longer a tab stays inactive, the higher the chance a phisher can strike, swapping the real page with a fake.

So, how do you prevent this? By adding rel="noopener noreferrer" to your anchor, like this:

<p>Learn to code for free at <a href ="https://www.freecodecamp.org/" target="_blank" rel="noopener noreferrer">freeCodeCamp.org!</a><p/>

Why use noopener and noreferrer?

Using noopener prevents bad actors and links from accessing the previous tab or window that opened the current one. This is done by setting the Window.opener() property to null.

Adding noreferrer prevents external sites from knowing that you've linked to them, which means your traffic data won't be sent their way.

Wrapping Up

You should now have an understanding of what tabnabbing is and how protect your links (and users) against it. Hope you found this helpful and best of luck to you!

If you have indeed found this helpful, I have more tech articles on my blog. If you want to connect, I'm on linkedin!

If you want to read more about all this, here are some resources:

1. EASYDMARC - What is Tabnabbing and how it works

2. Elegant Themes - What is the "noopener noreferrer" tag and what does it mean?

3. MDN - the Window.opener() property

Web security is an important aspect of the web application development process. Especially as more data is stored, managed, and shared.

As a web developer, it's essential to prioritize security measures to protect your company’s users and data from potential threats.

In this article, I will demonstrate web security best practices by building a secure web application using Django, a powerful Python web framework. I'll cover password hashing, secure session management, authentication, authorization, and other key security considerations with accompanying code examples.

Before continuing with this article, keep in mind that this isn't intended for absolute beginners. You should have a good understanding of Python to get the most out of this guide.

If you need to brush up on your basic programming skills in Python and Django before continuing, here are a couple resources to help you out:

• Python for Everybody from Dr. Chuck
• Django for Everybody, also from Dr. Chuck

You will get access to the code at the end of the article.

Set Up Your File Structure

Let's say that we want to store our project on the desktop. The first thing do is to set up our file structure. Let's start by creating a root directory for our project on the desktop (WebSec in this case).

mkdir WebSec
cd WebSec

Create a Virtual Environment and Activate It

On Linux (Ubuntu):

python3 -m venv my_env

Source my_env/bin/activate

And on Windows:

python -m venv my_env

my_env\Scripts\activate.bat

How to Create the Django Project

First, if you don't already have it, you'll need to install Django using the following command:

python -m pip install Django

Then you can use this command to create the project:

django-admin startproject web_sec_project .

And finally, use this command to create the app:

django-admin startapp web_sec_app

Your file structure should look like this at the end:

WebSec
    my_env/
    web_sec_app/
        __pycache__/
        migrations/
        templates/
        admin.py
        apps.py
        forms.py
        models.py
        tests.py
        urls.py
        views.py
    web_sec_project/
        __pycache__/
        __init__.py
        asgi.py
        settings.py
        urls.py
        wsgi.py
    db.sqlite3
    manage.py

Run Your Server

On your IDE terminal run the following command and test if your project is working. If so, you are good to go.

python manage.py runserver

Ensure that you add your app to your project:

Check that your app is added

Now let’s start building and implementing web security.

Password Hashing

The first line of defense when implementing web security is ensuring that user passwords are properly protected. And instead of storing passwords in plaintext, it's a good idea to hash them. We'll use cryptographic hashing to safeguard sensitive user information.

Cryptographic hashing, also known as hash functions or hash algorithms, is a fundamental concept in cryptography and computer security. It involves taking an input (or "message") and transforming it into a fixed-size string of characters, which is typically a sequence of numbers and letters. This output is called the "hash value" or "hash code."

Django provides a secure password hashing mechanism by default, using the PBKDF2 algorithm with a SHA-256 hash.

Django uses a robust and secure password hashing mechanism to protect user passwords. This mechanism helps ensure that even if the database is compromised, attackers cannot easily retrieve users' plaintext passwords. Django's password hashing mechanism consists of PBKDF2.

PBKDF2 is a simple cryptographic key derivation function that is resistant to dictionary attacks and rainbow table attacks. It is based on iteratively deriving HMAC many times with some padding. This ensures that even if the database is compromised, the passwords remain unreadable.

To demonstrate this, we are going to create a new user with a hashed password and save the user with their hashed password in the database.

First, we import the User from the User model. Then, we import make_password. Here's the code to do that:

#web_sec_app/views.py

from django.contrib.auth.hashers import make_password
from django.contrib.auth.models import User

# Create User views here.
def UserView(request):
    users = User.objects.all()
    password = 'password'
    hashed_password = make_password(password)
    return render(request, 'create_user.html', 
                {'users': users, 'hashed_password': hashed_password})

Secure Session Management

Session management is key to maintaining user state across multiple requests. Django comes with a built-in session management system that stores session data on the server-side. We'll ensure that the session data is encrypted and the session ID is secure to prevent session hijacking attacks.

To achieve secure session management, we will make sure we have a secure session cookie, which will require HTTPS. We are also going to prevent JavaScript access to the session cookie. The session expires when the browser is closed.

SESSION_COOKIE_SECURE = True

This setting tells Django to only send the session cookie over HTTPS connections. When set to True, the session cookie will not be sent over unencrypted HTTP connections. This is important for protecting sensitive session data, such as user authentication tokens, from being intercepted by malicious actors on insecure networks.

SESSION_COOKIE_HTTPONLY = True

Setting SESSION_COOKIE_HTTPONLY to True adds an extra layer of security. When this is enabled, the session cookie cannot be accessed by JavaScript code running on the client's browser. This helps mitigate certain types of cross-site scripting (XSS) attacks, where an attacker tries to steal session data using malicious scripts.

SESSION_EXPIRE_AT_BROWSER_CLOSE = True

When SESSION_EXPIRE_AT_BROWSER_CLOSE is set to True, the session will expire and be deleted once the user closes their web browser. This provides a mechanism for creating short-lived sessions that automatically end when the user finishes their browsing session. It's useful for scenarios where you want to ensure that users are logged out when they close their browser, enhancing security for shared or public computers.

Your settings.py file should contain the following:

SESSION_COOKIE_SECURE = True 
SESSION_COOKIE_HTTPONLY = True
SESSION_EXPIRE_AT_BROWSER_CLOSE = True

Authentication and Authorization

Proper authentication and authorization procedures are important for limiting access to certain parts of the web application.

In this section, I'll demonstrate how to implement user login and authentication using Django's authentication framework. I'll also define access control based on user roles to ensure that only authorized users can access certain views and features.

@user_passes_test(lambda u: u.is_superuser)
def admin(request):
    return render(request, 'admin.html', {'username': request.user.username})

The code above is used to restrict access to the admin view based on whether the user is a superuser (admin) or not.

If the user is a superuser, they are allowed to access the view, and the template admin.html is rendered with their username displayed. If the user is not a superuser, they will be redirected to a default unauthorized view, unless additional handling is implemented.

This ensures that only authorized users with admin privileges can access the 'admin.html' page.

Cross-Site Scripting (XSS) Protection

Cross-Site Scripting (XSS) is a common vulnerability that allows hackers to inject malicious scripts into web pages viewed by other users.

In this section, we'll explore how to implement Content Security Policy (CSP) headers to prevent unauthorized script execution and protect our application against XSS attacks.

CSP headers work by creating a set of rules that define which content sources are allowed and which are blocked. This significantly reduces the attack surface for XSS vulnerabilities, making it much harder for attackers to execute unauthorized scripts on your application.

It's important to carefully configure CSP policies to strike a balance between security and functionality, as overly restrictive policies could potentially break legitimate functionality in your application.

CSP_DEFAULT_SRC = ("'self'",)

Cross-Site Request Forgery (CSRF) Protection

CSRF attacks occur when malicious websites trick users into taking unauthorized actions on other sites where they are authenticated. Django offers built-in protection against CSRF attacks using CSRF tokens.

It is one of the most common methods used for preventing CSRF attacks using CSRF tokens.

When a user loads a web page that requires user interaction, the server generates a unique token and includes it in the form or the request data. This token is typically associated with the user's session. When the user submits the form or initiates an action, the server checks if the submitted token matches the one associated with the user's session. If they don't match, the request is rejected, as it might be an attempt to perform a CSRF attack.

I'll show you how to include these tokens in forms to prevent unauthorized requests.

<h4>Create Account</h4>
<form action="{% url 'create_user' %}" method="post">
   {% csrf_token %}
   <input 
      type="text" 
      id="userName" 
      name="username"
      class="form-control input-sm chat-input" 
      placeholder="username" 
    />
</form>

SQL Injection Prevention

SQL injection is a serious vulnerability that occurs when attackers manipulate user inputs to execute malicious SQL queries on the database. I'll demonstrate how Django's ORM (Object-Relational Mapping) automatically sanitizes user inputs and protects against SQL injection attacks.

It is important to note that even though Django's ORM offers robust defense against the majority of SQL injection attacks, developers must still adhere to best security practices, such as input validation and authorization checks, to guarantee the overall security of their web applications.

It's also a good idea to update Django and its dependencies frequently to take advantage of any security updates or other improvements that may be released in the future.

def search(request):
    query = request.GET.get('q')
    if query is not None:
        results = Search.objects.filter(Q(name__icontains=query) | Q(description__icontains=query))
    else:
        results = []
    return render(request, 'search.html', {'results': results})

The code above defines a Django view function that handles search functionality by extracting a query from the request's GET parameters, using that query to perform a search in the Search model using the Django ORM's filter method, and then rendering a template with the search results.

The search is performed based on the 'name' and 'description' fields of the model, and the results are case-insensitive partial matches.

By relying on Django's ORM and its built-in features, you're leveraging a higher level of abstraction that inherently helps prevent common SQL injection vulnerabilities.

This code's structure and usage patterns align with best practices for writing secure queries in Django, making it less susceptible to SQL injection attacks. But it's still important to ensure that the rest of your codebase follows security best practices and that you keep your Django version and dependencies up to date to benefit from the latest security patches.

File Upload Security

Handling file uploads requires special attention to prevent attackers from uploading malicious files. We'll see how to validate and restrict file uploads to ensure the security of our web application.

def upload_file(request):
    if request.method == 'POST':
        uploaded_file = request.FILES.get('file')
        if uploaded_file:
            if uploaded_file.content_type in ALLOWED_FILE_EXTENSIONS:
                try:
                    with open('uploads/' + uploaded_file.name, 'wb+') as destination:
                        for chunk in uploaded_file.chunks():
                            destination.write(chunk)
                    return render(request, 'success.html')
                except ValidationError as e:
                    error_message = str(e)
                    return render(request, 'fileUpload.html', {'error_message': error_message})
            else:
                error_message = "Invalid file type."
                return render(request, 'fileUpload.html', {'error_message': error_message})
        else:
            error_message = "No file selected."
            return render(request, 'fileUpload.html', {'error_message': error_message})
    else:
        return render(request, 'fileUpload.html')

The code snippet above defines a function called upload_file This function takes a request object as its argument and handles file uploads.

The function first checks if the request method is POST. If it is, then the function gets the file uploaded by the user using the request.FILES.get('file') method.

If the file is not empty, then the function checks if the file extension is in the ALLOWED_FILE_EXTENSIONS list. This list contains the file types that are allowed to be uploaded. If the file extension is not in the list, then the function displays an error message.

If the file extension is in the list, then the function tries to save the file to a directory called uploads. function uses the with open() statement to open the file in binary write mode. The file is then saved in chunks using the for chunk in file.chunks() loop.

If the file is saved successfully, then the function redirects the user to a success page. Otherwise, an error message is displayed.

The ALLOWED_FILE_EXTENSIONS list is a security measure that prevents users from uploading malicious files, such as executables or scripts. The maximum file size limit is another security measure that prevents users from uploading large files that could cause a denial-of-service attack. Storing the uploaded file in a separate directory isolates the file from the rest of the application and makes it more difficult for attackers to access it.

Wrapping-up

Building a secure web application is a continuous process that requires vigilance and implementing best practices.

In this article, I demonstrated various web security measures with code examples while building a web application using Django.

By implementing password hashing, secure session management, authentication, authorization, and protection against common web vulnerabilities like XSS and CSRF, I've taken important steps towards creating a robust and secure web application.

But web security is a vast and ever-evolving field, and it's crucial to stay updated with the latest security trends and practices to ensure your web application remains safe from potential threats. Always perform thorough security testing and regularly update your application and libraries to maintain a strong defense against potential attacks.

With the right security measures in place, you can confidently provide your users with a safe and secure web experience.

You can have access to the code here. Thanks for reading!

In today's digital landscape, search engine optimization (SEO) is important for increasing online visibility and driving organic traffic to websites.

But cybersecurity threats, including SEO poisoning, pose a great risks to both website owners and SEO efforts.

To fight these risks and safeguard websites, cybersecurity experts and SEO professionals need to collaborate.

What is SEO Poisoning?

Search engines such as Google work by presenting a list of web pages to users based on their search queries. These web pages are ranked according to the importance of their content.

While many SEO companies specialize in optimizing websites to better position them in these search results, attackers take advantage of popular search terms and use SEO to push malicious sites higher up the ranks. This technique is called SEO poisoning.

The most common goal of SEO poisoning is to increase traffic to malicious sites that may host malware or attempt social engineering.

In this article, we will explore the security measures that cybersecurity and SEO experts should implement to avoid SEO poisoning.

How to Protect Against SEO Poisoning

Collaboration between cybersecurity experts and SEO professionals is important if you want to establish a strong security foundation while optimizing a website for search engines.

By working together, these teams can combine their expertise to create a secure and optimized online presence.

Have Robust Website Security

Robust website security is the basis of protecting your online presence against various cyber threats. Two important aspects of this are implementing secure coding practices and ensuring that all components of your website are kept up-to-date.

Cybersecurity experts should focus on implementing robust security measures on the website. This includes using secure coding practices, regularly updating software and plugins, and employing web application firewalls (WAFs) to detect and prevent attacks.

By ensuring a secure website environment, you can significantly reduce the risk of SEO poisoning.

Secure Coding Practices

Secure coding practices involve writing code in a way that reduces vulnerabilities and weaknesses that could be exploited by attackers. Below are some examples of secure coding practices:

• Input Validation: Always validate and sanitize user inputs to prevent input-based attacks like SQL injection and cross-site scripting (XSS).
• Avoid Hardcoding Secrets: Avoid hardcoding sensitive information like passwords or API keys directly into the code. Instead, use environment variables or configuration files.
• Proper Authentication and Authorization: Implement strong authentication mechanisms and proper authorization controls to ensure that users can access only what they're authorized to.
• Error Handling: Implement proper error handling to avoid exposing sensitive system information to attackers and users.
• Use of Libraries and Frameworks: Use well-established libraries and frameworks that have undergone security reviews and have a track record of being secure.

Secure coding practices and regular updates are essential for maintaining a robust website security posture. By writing code securely and keeping software up-to-date, you significantly reduce the risk of security breaches and ensure the smooth operation of your online presence.

Use a Secure CMS and Plugins

SEO experts should carefully select reputable content management systems (CMS) and plugins that have a proven track record of security. Regularly updating them with the latest security patches is crucial to addressing vulnerabilities that could be exploited by attackers.

How to Evaluate the Security of a CMS

• Community and Development: A strong and active developer community is a positive sign. More eyes on the code mean faster identification and resolution of security issues.
• Regular Updates: Regular updates, especially security patches, are indicative of a CMS that takes security seriously. Avoid CMSs that have a history of infrequent or delayed updates.
• Authentication and Authorization: Check if the CMS supports strong user authentication mechanisms and proper authorization controls.
• Data Handling: A secure CMS should handle data, including user inputs and sensitive information, in a safe and encrypted manner.
• Vulnerability Reporting and Response: Look into the CMS's vulnerability reporting and response process. Do they have a clear mechanism for reporting vulnerabilities, and how quickly do they respond and release patches?

How to Evaluate Plugins and Extensions

• Source and Reputation: Download plugins only from reputable sources like the official plugin repository for the CMS. Avoid downloading plugins from third-party sites.
• User Ratings and Reviews: Check user reviews and ratings for plugins. If a plugin has a lot of positive reviews and a high user rating, it's generally a good sign.
• Regular Updates: Plugins that receive frequent updates are more likely to have active developers who are fixing vulnerabilities and adding features.
• Plugin Compatibility: Ensure that the plugin is compatible with the latest version of your CMS. Outdated plugins can introduce vulnerabilities.
• Permissions: Plugins should request only the necessary permissions. Be wary of plugins that require excessive permissions.

Remember no CMS or plugin can guarantee 100% security. Security is a collaborative effort that involves regularly updating both your CMS and plugins, as well as following secure coding practices when developing your website.

Perform Regular Security Audits

Both cybersecurity and SEO professionals should conduct regular security audits to identify potential vulnerabilities or weaknesses that could lead to SEO poisoning.

By reviewing website code, configuration files, and server settings, they can proactively address security gaps and ensure the integrity of SEO efforts.

Monitor for Suspicious Activities

SEO experts should be vigilant in monitoring SEO-related activities on the website. Sudden drops in search engine rankings, unusual keyword stuffing, unexpected redirects, or suspicious backlinks can indicate SEO poisoning attempts.

Promptly investigating and addressing such anomalies is important to preventing further damage.

Vigilant monitoring for unusual activities on your website is essential for early detection of SEO poisoning attempts. Here are some potential issues, why they might happen, and how to prevent them.

Sudden Drop in Search Engine Rankings

• What Happens: Your website's position in search engine results suddenly plummets.
• Why It Might Happen: It could be due to an algorithm change, but it might also be the result of a hacking attempt or SEO poisoning.
• Prevention: Regularly monitor your search engine rankings and organic traffic. Implement solid SEO practices to avoid potential penalties.

Keyword Stuffing

• What Happens: Pages on your site contain an excessive number of keywords, making content unnatural and difficult to read.
• Why It Might Happen: Malicious actors might try to manipulate search engine rankings through keyword stuffing.
• Prevention: Follow ethical SEO guidelines. Write content for users, not search engines. Use keywords naturally and provide valuable information.

Unexpected Redirects

• What Happens: Users are redirected to unrelated or malicious websites when they click on links on your site.
• Why It Might Happen: Hackers might inject malicious code into your website's files to redirect traffic for their benefit.
• Prevention: Regularly scan your website's code for any suspicious code injections. Keep your website software, themes, and plugins updated to the latest versions.

Unusual Backlinks

• What Happens: Your website has links from spammy or irrelevant sites that you didn't intend to associate with.
• Why It Might Happen: Competitors might engage in negative SEO to hurt your site's reputation or search rankings.
• Prevention: Monitor your backlink profile regularly. Use tools to disallow or remove unwanted backlinks. Build quality backlinks through ethical practices.

Unexplained Traffic Spikes:

• What Happens: Your website experiences sudden and unexpected surges in traffic.
• Why It Might Happen: It could be a sign of a Distributed Denial of Service (DDoS) attack, where attackers flood your site with traffic to overwhelm it.
• Prevention: Use web application firewalls (WAFs) to detect and mitigate DDoS attacks. Monitor your website's traffic patterns for anomalies.

Phishing Pages:

• What Happens: Attackers create fake pages on your site to steal sensitive information from users.
• Why It Might Happen: Hackers exploit vulnerabilities to inject malicious code, creating fake login or payment pages.
• Prevention: Regularly audit your website's files for unauthorized changes. Implement security plugins that scan for malicious code.

Unexpected Changes to Content:

• What Happens: Your website's content is altered without your authorization.
• Why It Might Happen: Attackers with unauthorized access might change content to spread malware or deface your site.
• Prevention: Enforce strong user authentication. Monitor your website for unauthorized changes using change detection tools.

By staying vigilant and proactively monitoring your website for these types of suspicious activities, SEO experts can quickly detect and respond to potential security threats. Implementing a combination of robust security measures, regular updates, and continuous monitoring will greatly enhance your website's resilience against cyber threats.

Validate User-Generated Content

To prevent the injection of malicious links or code through user-generated content, both cybersecurity and SEO experts should implement strict validation and filtering mechanisms.

Utilizing CAPTCHAs, moderation systems, and content filtering tools can help maintain a secure website environment.

Moderation Tools

Moderation tools enable manual or automated review of user-generated content before it's published on your website. They allow you to ensure that content adheres to your platform's guidelines and standards.

Some popular moderation tools include:

• Automated Profanity Filters: These tools automatically detect and block or flag content containing offensive language, slurs, or inappropriate words.
• Manual Review Queues: Content flagged by users or automated filters can be placed in a review queue for human moderators to assess before publishing.
• AI-Powered Moderation: Advanced AI algorithms can identify potentially harmful content, such as hate speech, violence, or explicit material, and flag it for review.

Content-Filtering Tools

Content-filtering tools use predefined rules to identify and block specific types of content. These tools are particularly useful for preventing the posting of malicious links or code.

Here's what to look for when considering these tools:

• URL Filtering: The tool should be able to detect and prevent the posting of malicious URLs that could lead to phishing sites, malware downloads, or other security risks.
• Code Validation: If your platform allows HTML or script embedding, ensure the tool can validate and block potentially harmful code to prevent cross-site scripting (XSS) attacks.
• Custom Rule Creation: The ability to create custom filtering rules tailored to your platform's specific needs is valuable for maintaining control over content.

By implementing a combination of moderation and content-filtering tools, SEO experts can create a safer and more positive user experience on websites. Regularly reviewing and updating filtering rules, as well as staying informed about emerging content threats, will help you maintain a secure user-generated content environment.

Educate Your Team and Raise Awareness

Both cybersecurity and SEO experts should educate website owners, staff, web maintainers, and clients about the risks of SEO poisoning and the importance of maintaining a secure website. Emphasize the need for strong passwords, regular updates, and secure hosting.

By promoting cybersecurity awareness, you can ensure the adoption of good security practices.

Also, make sure your teams stay updated on the latest security trends, SEO techniques, and emerging threats. This knowledge empowers them to proactively address vulnerabilities and implement effective countermeasures against SEO poisoning attacks.

Here are some recommended resources and ways to stay up-to-date as an expert.

Online Security News Portals

Websites like KrebsOnSecurity, Dark Reading, and Hacker News provide regular updates on the latest cybersecurity threats, vulnerabilities, and best practices.

Cybersecurity Blogs

Follow respected cybersecurity blogs such as Schneier on Security, Troy Hunt's Blog, and the SANS Internet Storm Center for in-depth analysis, insights, and commentary.

Social Media

Follow reputable cybersecurity experts and organizations on platforms like Twitter (X) and LinkedIn. They often share insights, news, and discussions about the latest trends and threats.

Industry Reports and White Papers

Organizations like Verizon, Ponemon Institute, and Symantec regularly release cybersecurity reports and whitepapers with valuable insights and statistics.

Webinars and Conferences

Participate in webinars and attend cybersecurity conferences like Black Hat, DEF CON, and RSA Conference. These events offer deep dives into cutting-edge security research and emerging threats.

Security Organizations

Join organizations like ISACA, (ISC)², and OWASP to access resources, research, and networking opportunities.

And here are some tips for SEO experts:

Google's Official Blogs

Google provides insights into algorithm updates, best practices, and changes through their blogs, like Google Webmaster Central Blog and Google Search Central Blog.

Moz and SEMrush

These platforms offer SEO tools and resources, including blogs, guides, and webinars, to keep you informed about the latest SEO trends and strategies.

Search Engine Land and Search Engine Journal

These websites provide daily news and analysis on search engine optimization, search engine marketing, and related topics.

YouTube Channels and Podcasts

Many SEO experts and agencies share their knowledge through video tutorials and podcasts. Channels like Brian Dean's Backlinko and podcasts like Experts On The Wire are valuable resources.

SEO Forums and Communities

Engage in discussions and share insights on platforms like WebmasterWorld, Reddit's r/SEO, and Inbound.org

SEO Training Courses

Platforms like Coursera, Udemy, and LinkedIn Learning offer SEO courses that cover foundational and advanced strategies.

Google Search Console and Google Analytics

Regularly check your website's performance metrics and search queries to stay updated on changes in user behavior and site visibility.

Remember to validate information from multiple trusted sources and consider cross-referencing with established experts. By consistently staying informed through these resources, you can stay ahead of the curve and implement effective cybersecurity measures and SEO strategies.

Optimize Your Website's Performance

SEO experts should optimize website performance to enhance the user experience and reduce the risk of SEO poisoning.

Fast-loading pages, mobile-friendly designs, and efficient website architecture not only contribute to better SEO rankings but also minimize the time visitors spend on potentially compromised pages.

Indirect Benefits of Good Website Performance in Preventing SEO Poisoning

A fast-loading website encourages users to stay longer and engage with your content. Users are less likely to leave a site that loads quickly, reducing the chances of them encountering poisoned content that might have been inserted by attackers.

Also, a high bounce rate (users leaving the site quickly after landing on a page) can signal to search engines that your site's content isn't relevant or useful. A fast site with engaging content can reduce bounce rates, helping maintain positive search engine rankings.

A fast site with efficient code and minimal security vulnerabilities reduces this window of opportunity for attackers.

On the other hand, a slow website can give attackers more time to exploit vulnerabilities and insert malicious content.

Slow websites can also put unnecessary strain on your server's resources. Attackers might leverage this to launch resource-intensive attacks like Distributed Denial of Service (DDoS). Optimizing your site's performance can help mitigate such risks.

Lastly, search engine bots crawl and index websites. A slow site can hinder this process, affecting how search engines index and rank your content. A well-optimized site ensures that your content is accurately crawled and indexed.

How to Optimize Website Performance

• Use compressed and properly sized images to reduce page load times.
• Minimize HTML, CSS, and JavaScript code to decrease load times.
• Leverage browser caching to store certain elements locally, reducing the need to download them repeatedly.
• Use a Content Delivery Network (CDN) to distribute content across multiple servers, reducing latency and improving load times.
• Minimize the number of requests your site makes to the server by combining CSS and JavaScript files.
• Optimize server settings, use caching mechanisms, and ensure efficient server resources allocation.
• Ensure your site is responsive and mobile-friendly for seamless performance across devices.
• Use efficient coding practices and consider asynchronous loading for scripts.

By focusing on website performance optimization, you indirectly bolster your site's resilience against potential security threats, including SEO poisoning. A fast, user-friendly website enhances user experience, reduces vulnerabilities, and contributes to a healthy online presence.

Perform Regular Backups and Have a Disaster Recovery Plan

Both cybersecurity and SEO experts should emphasize the importance of regular backups and make sure the company has a robust disaster recovery plan.

Backups allow companies to restore data to a known secure state in the event of an SEO poisoning attack or any other security incident.

Disaster Recovery Involves:

• Planning: Identifying potential risks, threats, and vulnerabilities that could lead to data loss or system downtime. This includes natural disasters, cyberattacks, hardware failures, and more.
• Backup and Restoration: Regularly create backups of critical data and systems to ensure that if a disaster occurs, you can restore your data and systems to a functional state.
• Testing: Regularly test your disaster recovery plan to ensure that backups are accessible and can be successfully restored. Testing helps identify any issues that need to be addressed before an actual disaster occurs.
• Communication: Developing a communication plan to keep stakeholders informed during a disaster. This includes notifying employees, customers, partners, and the public about the situation and the steps being taken to recover.
• Documentation: Keep detailed documentation of your disaster recovery plan, including procedures, contacts, and any necessary passwords or access information.

How to Recognize Malicious Sites from SEO Poisoning

Malicious sites often have content that's unrelated to the user's search query. If a site's content doesn't match what you're looking for, it could be a red flag.

Also, be cautious of sites with unprofessional designs, excessive ads, and cluttered layouts. Legitimate sites generally invest in good user experience.

Check the URL for unusual or misspelled words, extra characters, or subdomains that don't match the official site. Attackers might mimic legitimate domains to deceive users.

You should also be wary of domain names that look similar to popular sites but contain slight misspellings or variations. These are common in phishing attempts.

If a site promises unbelievable deals or offers that seem too good to be true, it's often a sign of a scam.

When you're using a legitimate website, it usually has clear contact information. If you can't find any contact details, it's a warning sign.

Additionally, poor spelling and grammar throughout the site can indicate a lack of professionalism and potentially malicious intent.

Finally, if the site doesn't have a padlock icon in the browser's address bar, it's not using a secure HTTPS connection, making your data vulnerable.

How to Avoid Malicious Sites

Malicious sites are out there, unfortunately. So here are some tips to help you recognize them and avoid them:

• Always double-check the URL to ensure it matches the official domain of the site you intend to visit.
• Search engines like Google sometimes display warnings next to potentially harmful sites in search results.
• Instead of clicking on links from search results, type the official website's URL directly into the browser.
• Install reputable antivirus and anti-malware software that can help detect and warn you about malicious sites.
• Regularly update your operating system, browsers, and plugins to benefit from the latest security patches.

Remember, attackers use SEO poisoning to lure users into interacting with malicious sites. By staying vigilant, practicing safe browsing habits, and being cautious when encountering unfamiliar websites, you can greatly reduce the risk of falling victim to SEO poisoning and other online threats.

Conclusion

Solid collaboration between cybersecurity experts and SEO professionals is crucial for maintaining website security and preventing SEO poisoning attacks.

By implementing robust security measures, conducting regular audits, monitoring for suspicious activities, and staying informed about emerging threats, they can protect websites from malicious manipulation.

Educating website owners and clients about the importance of security and following best practices further strengthens the defense against SEO poisoning.

With a collaborative and proactive approach, cybersecurity and SEO experts can ensure the integrity of websites and optimize their online presence effectively.

Website security issues and vulnerabilities are a global problem as cyber security vulnerabilities are increasing. We have seen a major rise in the average number of these cases in the past few years, and 2021 saw an all-time high.

So in this tutorial, we are going to talk about DOM XSS cross-site scripting security issues and what impact they can have on your data. Make sure you read till the end. Let's begin by brushing up on some basics about DOM XSS cross-site script security.

What is Cross-Site Scripting?

Cross-site scripting, also called XSS, is a website security issue that compromises user information and data when those people use a vulnerable application. The attacker can use this to circumvent the origin policy, which separates two websites from one another.

Attackers may use XSS to pretend to be a user, perform actions that a user would, and gain access to the user’s information. This can also allow the attackers to gain full access to the user’s information if they have permissions and privileges. It can also take over the complete actions and performance of the website if this continues.

To help you better understand these types of attacks, we are going to discuss some fundamentals of how XSS operates and what it does.

How Does XSS Work?

Cross-site scripting uses technology to manipulate a vulnerable site so that it sends dangerous JavaScript to users. This allows the attacker to gain complete access to the site when the script gains access to the user’s system. But the user needs to execute the JavaScript for this first.

Types of XSS Attacks

Reflected XSS:

This malicious script comes from the HTTP request. This is the most basic type of XSS attack, where an application could receive malicious data and reflect it immediately towards the user.

The attacker’s payload must be part of the request sent to a server, which is then reflected and executed onto the user’s application.

One example of this would be an attacker convincing someone to click on a phishing link before it takes effect.

Stored XSS:

This malicious script comes from the database of the website. The attacker inputs the malicious request onto the server where it could stay permanently unless manually addressed.

For example, the attacker could input a malicious script into a comment field, which would be on display for everyone who visits the page. Even without directly engaging with the script, page visitors could fall victim to this attack.

DOM-based XSS:

This more advanced vulnerability exists in client code and not on the server code. DOM-based XSS is neither reflected nor stored onto the server, but exists in a page’s Document Object Model (DOM). The web application reads the malicious code and executes it in the browser as part of the DOM, which is more difficult to detect as it doesn’t come through the server.

The security vulnerabilities involved in DOM XSS attacks are a serious concern for most websites. We are going to talk about some of the most common risks that you have on open source web building platforms such as WordPress with regard to DOM - XSS hacks.

This allows the attacker to execute malicious JavaScript code in the victim's browser, potentially allowing the attacker to steal sensitive information or perform other harmful actions on the victim's behalf.

Here is an example of a DOM-based XSS attack:

<script>
 // This function is intended to take a user supplied URL and display it on the page
 function displayURL(url) {
  // The URL is passed through innerHTML, which can execute JavaScript code
  document.getElementById("display").innerHTML = url;
 }
</script>

<!-- User supplied input is passed to the displayURL function -->
<p>Enter a URL to display: <input type="text" id="user-input" /></p>
<button onclick="displayURL(document.getElementById('user-input').value)">
 Display URL
</button>

<!-- The URL is displayed in this div -->
<div id="display"></div>

Remember that this tutorial is purely for educational purposes, to help you recognize and defend against XSS. You shouldn't use this information to perform any of these sorts of attacks.

DOM XSS – WordPress Vulnerabilities

The main target of DOM XSS attacks on WordPress is its users. Users enter their details, accounts, and site credentials to access their WordPress sites and this is what the DOM XSS attacks aim to compromise online. The attackers can use DOM XSS to get access to user information and details with a single click.

This also includes your cookies, information, and others, making it one of the most common WordPress security vulnerabilities.

Following are some of the top WordPress website security issues you should bear in mind to ensure better cross-site script security.

Accessing a User's Private Information

One of the most common WordPress security vulnerabilities involved with DOM XSS attacks is that attackers can gain useful information and even completely take over a user’s site. This can often make things escalate fast and cause complete data compromise.

Impersonating a User

Attackers can pretend to be the user, to interact with the victim’s online users, clients, and customers to gain their information.

Compromising a Site

Another common cross-site scripting security issue with websites is that these attacks can compromise the website and take access from the user. This includes displaying deviating content on the site (or content that is not originally from the site).

Other cases may involve changing the way WordPress looks online. Other people may also exploit the website by installing explicit content.

Social Engineering

In more severe cases, attackers may impact the WordPress site through phishing attempts. This is a common concern for web builder security vulnerabilities that we will discuss shortly.

The impact of XSS cross script-security issues varies for each website. However, WordPress sites are usually at a higher risk of these kinds of compromises because users save their personal information on the website. The risk increases further if the user is an admin, as the attacker can compromise the complete WordPress site.

DOM XSS and Closed Code Web Builder Platforms

Website builders such as Weebly, Squarespace, Webflow and Wix, unlike WordPress, are non-open source platforms. They allow users to intuitively create websites for their businesses via drag and drop DIY features without any coding or design experience. They also work hard to protect their users' security.

There are tons of useful tools, options, easy-to-integrate dashboards, and hosting opportunities available for users instilling their trust in these platforms. Website security issues are of course a major concern for the majority of the users on these platforms.

Many website builders try their best to protect the sites of their users from hacker threats. But out of all of the website builders available, I believe that Wix follows the NIST framework for cyber security the best and has become a major contributor to improvements in this field.

Wix protects users on their sites from being vulnerable to these kinds of attacks online with tools such as:

• Third-party updates that project against DOM XSS attacks
• A secure Sockets Layer that protects against unwanted access for users on site
• Round-the-clock secure web hosting which protects users against any kind of unwanted logins or phishing attempts.
• Granting its users admin privileges, which restrict site access and control to the original owner only
• Highlighting weak passwords and suggesting more difficult-to-decipher passwords.

Ways to Protect Against XSS Attacks

Defending your system and users against XSS attacks often requires a multifaceted approach to ensure that your servers and applications are protected against various types of attacks.

The best way to defend against XSS attacks is to properly sanitize user input. This means making sure that any user input is properly encoded so that it cannot be interpreted as code by the browser.

Additionally, you can use a web application firewall (WAF) to help identify and block XSS attacks. It's also a good idea to keep your software and web applications up to date, as many XSS vulnerabilities can be mitigated by simply applying the latest security patches.

Input Validation

This programming technique ensures that only properly-formatted data can enter a software system. Websites can either allow or block certain values to ensure that no XSS can penetrate their servers.

Escaping or Encoding User Input

Encoding and escaping changes user input to make them safer for the system. Encoding replaces special characters with more harmless equivalents (for example, translating < to <), while escaping adds special characters to protect against injection attacks.

Implementing a Content Security Policy (CSP)

Content security policies help administrators mitigate XSS attacks by restricting the resources a page can load at a given time. These resources can include scripts and images that could potentially harm clients and servers.

Bottom Line

DOM XSS cross-site scripting security issues are a serious concern for users on websites. But closed code web building platforms provide features like admin privileges, password best practices, 3^rd party updates, and much more. These features make them a more secure website building option than many open code platforms.

You can also prevent XSS attacks by filtering input once it arrives. You can do this by ensuring that only valid input is accepted.

When encoding data on output, the process should be done in HTTP responses so it will not be read as active content. More complex coding might be required, such as applying combinations of URL, JavaScript, CSS, and HTML encoding, depending on the context of output.

Keep response headers in check so browsers will have an appropriate interpretation of content.

Finally, use Content Security Policy (CSP) to minimize the severity of XSS attacks.

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';">

This CSP will allow your website to load scripts and styles from the same origin (that is, your own website), but it will block scripts and styles from external sources. It will also allow the use of inline scripts and styles, but it will block eval() statements, which can be used to execute arbitrary code.

Of course, this is just a simple example, and you can customize your CSP to suit your specific needs. For more information on how to use CSPs to defend against XSS attacks, you can refer to the Content Security Policy Level 2 specification.

Feature image via Unsplash (Florian Olivo).

In this article, we will learn how to use Ffuf, a fast web fuzzer written in Go. You will learn how to fuzz your way to find directories and files and bypass the authentication of a website using ffuf. Then you'll learn how to defend against these types of attacks.

Remember – to protect yourself and your websites, it helps to know how an attacker would try to get in. That way, you can more effectively keep them out.

Note: Before we dive into using ffuf, I would like to emphasize that this tutorial is only meant to help you defend yourself against fuzzing attacks. If you use this material for malicious purposes, I am not responsible.

What is FFuf?

Ffuf is a fuzzer written in the Go programming language.

Ffuf belongs to the exploitation phase in the pentesting lifecycle. It is also the fastest open-source fuzzing tool available in the market.

But before we start using Ffuf, let's understand what fuzzing is.

What is Fuzzing?

Fuzzing is a method of sending malformed or abnormal data to a system in order to get it to misbehave in some way, which could lead to the discovery of vulnerabilities.

Finding hidden files, sending random data to forms, or even login attempts to web applications can be considered fuzzing.

Then you might be wondering “How is it different from Brute forcing?”.

Brute forcing can be considered a part of fuzzing. In brute force, the attacker uses valid data, for example, to check if a login attempt works. But with Fuzzing, they can send random data to break the expected behavior of a system.

For example, if you use a tool like Ffuf and load it with hundreds of username-password combinations to try on a website, it is fuzzing. And that’s exactly what we will do using Ffuf.

Make sure you have written permission if you are going to try this tool on a third-party website.

How to Install Ffuf and Wordlists

Ffuf comes pre-packaged with the Kali Linux distribution. If you want to install Ffuf on your personal computer, here are the instructions.

Since Ffuf is written in the Go programming language, make sure you have the Go compiler installed in your system before trying to install Ffuf.

If you are new to wordlists, a wordlist is a list of commonly used terms. This can be a password wordlist, username wordlist, subdomain wordlist, and so on. You can find a lot of useful wordlists here.

I would recommend downloading Seclists. Seclists is a collection of multiple types of lists used during security assessments. This includes usernames, passwords, URLs, etc. If you are using Kali Linux, you can find seclists under /usr/share/wordlists.

To try this tool in real-time, you can either use your own website or use a practice web app like the Damn Vulnerable Web app (DVWA). DVWA is an intentionally misconfigured vulnerable web application that is used by pen testers for practicing web application attacks.

Fuzzing with Ffuf

Now that you understand what Fuzzing and Wordlists are, let's start using Ffuf.

We will use ffuf to fuzz the web application to discover directories, find usernames, enumerate virtual hosts, and even brute-force email/password combinations.

You can use the help command (-h) if you want to quickly look at the options provided by Ffuf. This is useful since you don't have to memorize all the options provided by Ffuf.

ffuf -h

Do remember that the URL (-u) and wordlist (-w) parameters are always required.

Note that I'll be using http://localhost:3000 for my examples. If you setup your own web app or use an existing website, you have to replace “localhost:3000” with the ip address or the domain name of the website.

How to Enumerate URLs with Ffuf

Let's see how to find some URL paths.

Finding URLs is useful, especially if they are being hidden from being publicly indexed. We will use the web content wordlist from seclists to fuzz the web app for hidden URLs.

You can use the following command to look for URLs:

ffuf -u http://localhost:3000/FUZZ -w /usr/share/wordlists/SecLists/Discovery/Web-Content/big.txt

Here, the “FUZZ” keyword is used as a placeholder. Ffuf will try to hit the URL by replacing the word “FUZZ” with every word in the wordlist.

Here is what I found from the DVWA:

Result of looking for URLs

Interesting. You can see that we have found a few (possibly important) locations like /config, /docs, and /server-status.

If a real-world web app had pages that were not linked anywhere but used standard names, Ffuf would easily spot them.

How to Enumerate Files with Ffuf

What if you want to look for specific files? Thankfully, Ffuf provides us with the extension option (-e) that we can use. We can tell Ffuf to look only for files that have certain extensions – in our case, .html,.php, and .txt.

We will be using the raft-medium-words wordlist for this. Here is the command to look for specific files:

ffuf -u http://localhost:3000/FUZZ -w /usr/share/wordlists/SecLists/Discovery/Web-Content/raft-medium-words-lowercase.txt -e .php,.html,.txt

This command looks for all the files at the root of the domain with an extension of .html, .php, and .txt. Here is the result from DVWA:

Result of looking for specific files

We have found a long list of files. Even if some files are not served on the web app (403 status), we can learn that there are files, just that we cannot access them yet.

Let’s run the same command, but now, we will only look for files that are accessible to the public. We will use the match code (-mc) flag to only look for files with a status of 200.

Here is the command:

ffuf -u http://localhost:3000/FUZZ -w /usr/share/wordlists/SecLists/Discovery/Web-Content/raft-medium-words-lowercase.txt -e .php,.html,.txt -mc 200

And here is the result.

Files accessible to the public

You can see that we have found a few files that we can access. The login.php looks interesting, and we will use it for bypassing authentication in the following sections.

How to Enumerate Sub Domains using Ffuf

You can also look for sub-domains in a web app using Ffuf.

You might have guessed the approach that we are going to use. We will replace the subdomain of the URL with the word “FUZZ” and try looking for URLs that are up.

Since my web app is hosted on my local system, it does not contain any subdomains. But in the real world, if you want to enumerate subdomains, here is the command. You can use the sub domains wordlist from seclists.

ffuf -u http://FUZZ.mydomain.com -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

How to Find Usernames with Ffuf

Have you been annoyed when web applications don’t tell you whether you have the wrong username or password? They just tell you “This combination doesn’t work”.

This is to protect the web app from username/email fuzzing attacks. If authentication systems give you specific information about your login attempt, it gets easier for attackers to brute force and discover a list of usernames or emails.

Let’s assume that our web application tells you that you have the wrong username with the message “username does not exist”. We can use this error message to find valid usernames with the following command:

ffuf -w /usr/share/SecLists/Usernames/top-usernames-shortlist.txt -X POST -d "username=FUZZ&&password=x" -H "Content-Type: application/x-www-form-urlencoded" -u http://mydomain.com/login -mr "username already exists"

Here, we are sending POST requests to the login page, with the fuzzed usernames and a dummy password to check if the expected error message is returned. You can use a username wordlist from seclists for fuzzing.

The -mr flag is used to match a regular expression. You can have complicated regular expressions or a simple string message to validate the requests.

Here is a sample response.

Brute Forcing using Ffuf

Now, let's do some brute forcing with Ffuf. We will try a bunch of common username/password combinations and see if anything works.

If the web application you are testing uses a combination of email and password, you can replace the username wordlist with a email wordlist.

So for this attack, we need two parameters: username and password. Also, we will be using two-word lists: as you guessed, a username wordlist and a password wordlist.

In addition the default placeholder FUZZ, Ffuf supports the use of variables. So we will use W1 for our username wordlist and W2 for the password wordlist.

Here is the command:

ffuf -w usernames.txt:W1,/usr/share/wordlists/SecLists/Passwords/Common-Credentials/10-million-password-list-top-100.txt:W2 -X POST -d "username=W1&password=W2" -H "Content-Type: application/x-www-form-urlencoded" -u http://localhost:3000/login -fc 200

If Ffuf finds any valid combinations, you will see the combination in the results. You can also filter by status codes (for examle filter 400 or look for 200) using the -fc or -mc flags to reduce the noise.

Here is a sample response.

That was fun, wasn’t it? We can find a lot of interesting information about a web app without using a complicated tool like Burpsuite.

How to Protect Your Site from Fuzzing

But since we are not the malicious attackers, let’s look at how to defend against fuzzing.

The easiest way to protect your website from fuzzing attacks is to be careful about the type of files on the web server. If you don't want something to be found, don't put it on the web server.

To prevent authentication bypass, it is important not to allow multiple attempts to log in. Most modern websites don't allow more than 5 consecutive login attempts. It is more secure to ask your users to reset their passwords via email instead of letting them try multiple combinations.

You should also be careful about the error messages returned on failed attempts. Displaying that “Email does not exist” or “Password not correct” will let the hacker know that an email or username exists. This just makes their job easier.

Finally, you can use Web Application Firewalls (WAF) to monitor traffic and block suspicious IP addresses. WAFs also have options to set alerts if it comes across brute forcing attempts on your authentication methods.

Summary

Ffuf is a great tool to have in your pentesting toolkit. It is a simple yet fast fuzzer that makes it easy to enumerate directories, discover virtual hosts, and brute-force web applications.

Ffuf also has more options that will help you to look for specific information. It has support for regular expressions, rate limiting of requests, and saving your results to a file.

Hope you enjoyed this article. You can connect with me on Linkedin or read more articles on my blog. I’ll see you soon with another article.

CSRF is a malicious activity that involves an attacker performing actions on behalf of an authenticated user. Fortunately, Laravel provides out-of-the-box measures to prevent this type of vulnerability.

In this tutorial, you'll learn:

• What is CSRF?
• How to prevent a CSRF request
• How and where CSRF verification happens

What is CSRF?

CSRF attacks hijack user sessions. They do this by tricking a user into sending a request through hidden form tags or malicious URLs (images or links) without the user's knowledge.

This attack leads to a change in the state of the user session, data leaks, and attackers can sometimes manipulate end-users data in an application.

CSRF Explainer

The image above illustrates this scenario where an Actor (User) sends a request from malicious.xyz through the webserver to application.xyz. They then realize that their information has been manipulated by updating their password.

How to Prevent CSRF Requests

For each user session, Laravel generates secured tokens that it uses to ensure that the authenticated user is the one requesting the application.

Since this token changes each time a user session is regenerated, a malicious attacker can not access it.

Each time there’s a request to modify user information on the server-side (back end) like POST, PUT, PATCH, and DELETE, you need to include a @csrf in the HTML form request. The @csrf is thus a Blade directive used to generate a hidden token validated by the application.

Blade directive is the syntax used within the Laravel templating engine called Blade. To create a blade file you give it a name – in our case form – followed by the blade extension. This means that the file will have the name form.blade.php.

You use the blade file to render views to users on the webpage. There are a couple of default directives or blade shorthand syntaxes you can use. For example, @if checks if a condition is met, @empty checks if records are not empty, @auth checks if a user is authenticated, and so on.

But here we are more interested with the @csrf directive. Here's how you use it:

<form method="POST" action="{{route('pay')}}">

    @csrf

</form>

Earlier Laravel releases used to look somewhat like this – both work and do the same thing behind the scenes.

<form method="POST" action="{{route('pay')}}">

    <input type="hidden" name="_token" value="{{ csrf_token() }}" />

</form>

When the CSRF token is not present in the form request that gets sent or if it appears invalid, Laravel throws an error message "Page Expired" with a status code 419.

Laravel 419 Page Expired

How and Where CSRF Verification Happens

The VerifyCsrfToken middleware handles CSRF verification within the Laravel application. The middleware is registered in the Kernel.php, and found within the application's web route middleware group. This means the middleware is triggered for requests within the Web, not related to APIs.

protected $middlewareGroups = [
        'web' => [
           .
           .
           .
           .
           .
            \App\Http\Middleware\VerifyCsrfToken::class,
        ],
    ];

The VerifyCsrfToken middleware extends the Illuminate\Foundation\Http\Middleware\VerifyCsrfToken class. This means that the CSRF verification is housed within the class.

Let's dive deeper to learn how Laravel handles the CSRF verification.

Within the class, we have the tokensMatch function.

protected function tokensMatch($request)
    {
        $token = $this->getTokenFromRequest($request);

        return is_string($request->session()->token()) &&
               is_string($token) &&
               hash_equals($request->session()->token(), $token);
    }

The function does two things:

1. $this->getTokenFromRequest gets the token from the incoming request attached via a hidden field or the request's header. The token is decrypted and then returned to the token variable.

protected function getTokenFromRequest($request)
    {
        $token = $request->input('_token') ?: $request->header('X-CSRF-TOKEN');

        if (! $token && $header = $request->header('X-XSRF-TOKEN')) {
            try {
                $token = CookieValuePrefix::remove($this->encrypter->decrypt($header, static::serialized()));
            } catch (DecryptException $e) {
                $token = '';
            }
        }

        return $token;
    }

2. Cast both request token and session to a string and then use the PHP built-in hash_equals to compare if both strings are equal using the same time. The result of this operation is always a bool (true) or (false).

Wrapping up

In this article, you have learned about CSRF, how to handle and protect against it, and the behind-the-scenes of how Laravel does the verification.

You can read more about this in the Laravel documentation. And you can read more about PHP hash equals in the docs here.

Happy Coding!

How do you protect yourself online without having to remember a million impossible passwords?

This is an (actually) easy to implement guide, which is the digital equivalent of locking your house when you leave.

Taking these steps won’t make you hack-proof (just as locking your house won’t make your house burglar-proof) but it will make you much safer online. It also won’t make your digital life any harder than carrying keys makes your day-to-day life.

If you're convinced that this is too much work, start with one item at a time. If you're really insistent on not reading the whole list, start with the first 5 items here.

How to Protect Yourself Online

Set Passwords on All Your Devices

Setting passwords on all your devices – like laptops, phones, tablets, routers, and so on – is the first order of business.

For any devices which still have default passwords enabled, change them (think about your wifi router, a home camera system like Amazon’s Blink, or a smart TV).

Don't reuse your passwords. That can be very difficult, but a tool like a password manager can make that much easier. Which brings us to...

Use a Password Manager

Password managers let you create one ‘master password’ and then securely store (and generate) your strong, unique passwords for each account. They give you the security of having separate passwords for every account, but the convenience of only having to remember one password.

I love 1Password ($3/month) as it has an app and a browser extension (so it can autofill your passwords for you across apps and devices), but KeePass is a secure free option.

Password managers also allow you to securely store all kinds of information such as insurance numbers, bank account data, and so on. Think of it as the digital equivalent of having a fire-proof box with all your important documents.

Setting it up the first time (and putting all your accounts and passwords into it) is a giant pain. So go do it now. Seriously, I’ll wait.

Go back and do step 2.

At least put your bank and credit card accounts, email accounts, and social media into your new password manager. Spend 5 minutes a day adding new accounts to your password manager. Over time, it will save you a significant amount of time and stress.

Why? Often when passwords are leaked in a breach, hackers will use something called ‘credential stuffing’. That means they will take that password and plug it into an automated tool which will try using it in as many accounts as possible. If all your accounts have the same password, either your accounts could get breached, or you have to change ALL of your passwords every time you hear about a new breach.

Skip the stress and get a password manager (also, set up (free!) alerts here so you know when your account data has been leaked).

Update EVERYTHING.

Don’t click postpone or ignore on those pop up updates. Software updates are most often released in response to reported security vulnerabilities. Leaving your devices unpatched can leave them vulnerable to attack.

Back Up Your Data Regularly

You'll want to back up your data in case you are infected with malware. You can use iCloud (but make sure you've used a secure password!), other cloud service, or a physical hard drive (I use this one).

Use Antivirus Software (and Update it Regularly).

If you can afford it, antivirus is a good idea. It's not perfect, but it's better than nothing and typically a good idea for the average user. I use Malware Bytes.

Limit the Number of Internet-Connected Devices You Have.

Think before purchasing devices with internet connectivity. Is an internet connected kettle worth the potential security vulnerabilities (spoiler alert: it usually isn’t.)?

Internet of Things devices are rarely updated and generally aren’t designed with security in mind. That means they’re often riddled with vulnerabilities. And if they’re on your home wifi network, can leave hackers an easy way in.

Often (but not always), more expensive devices will do a better job of protecting your security.

Regularly Review Your Social Media Privacy Settings.

You might be surprised at how much information is being shared. When creating new social media accounts or posts, think before you post it. The more information hackers have on you, the easier their job is.

Try to avoid posting too much personal information on your social media pages, as well as avoiding posting things like pictures of your credit card or boarding pass.

For folks who rely on social media as an income stream, wipe the metadata from your photos and videos before posting (metadata can include specific location and device information which can be accessed by anyone viewing the photo/video).

Avoid Connecting to Free Wifi Hotspots.

Free wifi hotspots are often targeted by hackers and can put you at risk of MitM attacks (Man in the Middle Attacks) where a hacker spies on your internet traffic, and may even modify it without you knowing.

If you can’t avoid connecting to these hotspots, buy a VPN service.

Buy a VPN service.

A VPN (virtual private network) provides online privacy and anonymity. This can protect you, even when you connect to public wifi hotspots.

I recommend using one which you can install it on multiple devices, enable automatic connection (so as soon as you connect to the internet you are automatically connected to the VPN), and select which country you want your traffic to come from.

The TOR browser is a free service, however it is less convenient, and can slow down your connection speed.

Enable Multi-Factor Authentication on Your Primary Email Account.

Also known as MFA, or 2FA for 2 Factor authentication. This means that even if someone has your password, they can’t access your account.

Multi-factor authentication requires that you have two things to login: something you know (your password) and something you have (a code from an SMS, a code from an app like Google Authenticator, or a hardware key like YubiKey).

A hardware key is best, followed by an app, followed by SMS (which is still better than nothing).

If you’re feeling really motivated, also do so on your other accounts, but at least do so on your most important accounts. For a full list of websites which support 2FA, check here.

Use an End to End Encrypted Chat Application.

End to end encryption means that your data is encrypted on the device, and that no one can read or change your message in transit (not your internet service provider (ISP), hackers, and so on).

In order for someone to read this type of message, generally a hacker would have to have access to your device already. iMessage, WhatsApp, Wickr, and Signal are all free options, and Facebook Messenger is secure if you choose the ‘secret’ option when starting a chat.

Personally, I highly recommend Signal, as it’s open-source, free, and not owned by any major tech companies.

Check out MySudo and Privacy.

MySudo provides phone numbers via an app with plans starting at $0.99/month.

These are really great for using on dating apps, food delivery apps, or any other time when you may not want to give out your personal number (because your personal phone number is being used as a password reset option or as a form of multifactor authentication).

They also provide virtual debit cards (though Privacy offers better virtual card options for free). Think of this as the online version of paying with pre-paid Visa cards. You can have a unique debit card number for every single purchase online so you don't have to worry the next time a vendor gets breached and credit card details are stolen.

Finally, Be Careful Online.

Be wary of clicking links from unknown senders (in strange social media requests, texts, or emails), avoid running programs like Adobe Flash (which is notoriously insecure), and avoid websites which might give you malware (adult video streaming sites are often loaded with malicious content, as are free streaming or download sites).

If you need to access the link in an email (such as an alert from your bank or social media accounts), navigate to the app or website directly, rather than clicking the link in the email.

At the end of the day, don’t overthink it.

https://xkcd.com/538/

Want to learn more?

• What to do if your information was included in a data breach
• The Motherboard Guide to Not Getting Hacked
• The WIRED Guide to Digital Security

We interact with HTTP and HTTPS a lot in our day-to-day lives, but many people don't know the difference.

Most computer users just see that the browser is telling them their application is not safe and that a hacker might want to steal their important information. This leads to users running away faster than Usain Bolt's current record.

But this is avoidable. That is where HTTPS comes in and replaces HTTP. And we are going to discuss that today. :)

Here's What We'll Cover:

1. What is HTTP?
2. How HTTP works
3. Features of HTTP
4. How to know if a site is not secure
5. Are all HTTP websites insecure?
6. What is HTTPS?
7. How HTTPS works
8. Features of HTTPS
9. How encryption works
10. How to know if a site is secure
11. What is an SSL certificate?
12. How does SSL work?
13. How can I get SSL for my website?
14. Where can I get an SSL certificate?
15. Can I get an SSL certificate for free?
16. The main differences between HTTPS and HTTP
17. Conclusion

What is HTTP?

Hyper Text Transfer Protocol, or HTTP, is a communication method between your browser and the site you want to visit (web server).

This allows you to get the information that you need from the server on your browser.

A good way to understand HTTP and HTTPS is by using an analogy. We know that browsers and servers communicate using HTTP. HTTP is usually in plain text. Many people around the world speak English. If a hacker who knows English hacks into your computer, they can easily see any password you input.

Here in Kenya, in my mother tongue, we speak Turkana. If you don't speak the language and you come to Kenya and find two Turkanas speaking, you may not understand what they are saying.

That's the beauty of HTTPS. It is encrypted so that the hacker hopefully doesn't understand the communication between the browser and the server.


If I was to go to http://www.google.com, I would expect to see Google's default page.


The client, which in most cases is the web browser, sends a message which in computer terms is a request. Then the server will give back an answer, which is the response.

HTTP is very useful in sending HTML documents as well as images and videos to the web browser for the user to see. It is also used to send data to the server in HTML forms.


How HTTP Works

HTTP sends data through plain text. For example, if you were to access your bank's web page and they are using HTTP, a hacker may be able to access it and read any information that you send.

This is where HTTPS comes in. Many companies have implemented HTTPS to be able to allow their users to send data securely. We'll discuss this further below.

Features of HTTP

• Plain text. Initially when HTTP was developed, developers had one thing in mind: to serve only text documents. Now, HTTP is used in more ways than it was initially intended.

• Layer 7 protocol. HTTP is a layer 7 protocol in the OSI Model of networking. Layer 7 is the application layer. This layer is the top-most layer in the OSI model. The other layers include the physical, data link, network, transport, session, and presentation layer. To learn more about the OSI model, you can check out this free video on freeCodeCamp's YouTube channel by Brian Ferrill about how the internet works. There are more cookies in the jar other than the OSI model. Computer Networking Course - Network Engineering [CompTIA Network+ Exam Prep]

• Insecure. When you send HTTP requests they are sent through plain text. Also, when you get a response, you get it through plain text. This means that anyone who can access the requests and the responses can read them. 

• Light weight. The advantage of HTTP is that it is very lightweight. It is therefore very fast since it doesn't do the encryption stuff to secure the data, like HTTPS does.
• HTTP usually listens on port 80.

How to Know if a Site is Not Secure

When a site is not secure, Chrome will usually send a warning that says Your connection is not private. 

On Chrome, the URL bar will usually show Not Secure in red if a site is not secure. 

Are All HTTP Websites Insecure?

Well, let's look at an example. Imagine you are browsing a meme website, laughing at each one as you scroll by. If it is using HTTP, then you are off the hook. It's not a big deal.

You get bored and decide to go to your bank's site to access your account on your browser. If the site is not using HTTPS, you might as well be serving your account details to a hacker on a silver plate.

So the bottom line is, if you're browsing inconsequential information, HTTP is ok. But if you are dealing with insecure information, HTTP isn't enough.

What is HTTPS?

Hyper Text Transfer Protocol Secure, or HTTPS, is a way that communication can happen SECURELY between your browser and the site you want to visit (web server).

How HTTPS Works

HTTPS makes a secure connection by using a secure protocol that encrypts your data.

For most websites, the best way to have HTTPS is by getting an SSL (Secure Sockets Layer) Certificate or a TLS (Transport Layer Security) certificate.

At the moment, SSL has become advanced enough that it supports TLS. So you don't need to get a TLS certificate.

Features of HTTPS

• Encrypts data. Data encryption happens through the TLS/SSL protocol.
• It is a layer 4 (Transport layer) protocol.
• Key exchanges of public and private keys happen in HTTPS to encypt and decrypt data.
• Compared to HTTP, is it heavier. When encrpytion and decryption happens in HTTPS, it becomes heavier.
• HTTP listens on port 443.

  How Encryption Works


Let's say I type "I am a dev". This text gets encrypted when I click send, and then it gets decrypted on the server side.

The same is also true from the server side. If I get a response from the server, it will first get encrypted, then it will get decrypted on the client side.

How to Know if a Site is Secure

To know that a site is secure, you usually look at the URL bar where you can see a lock. If there is a lock, the connection from the client to the server is secure.


When you click on the lock icon, it tells you more about the secure connection.


What is an SSL Certificate?

An SSL certificate is a little file that tells browsers that your website –for example, freecodecamp.org – is who it says it is, and that it is reliable.

In order to authenticate, the certificate is able to confirm to the client (user) that the server they are connecting to is the one that manages that domain. All this is to keep the user safe from security issues such as domain spoofing.

It contains a public key and tells you who the owner of the website is that you are trying to connect to. If a website doesn't have an SSL certificate, it cannot be encrypted with TLS.

You can personally create your own SSL certificate (also known as a self-signed certificate), if you are the website owner. The problem with this approach is that browsers like Chrome don't trust these certificates. They prefer trusting certificates that are issued by a certificate authority.

How Does SSL Encryption Work?

There are two types of SSL encryption, asymmetric and symmetric. The combination of asymmetric and symmetric is what makes SSL Encryption work. Let's look at them below to learn more.

What is asymmetric encryption?

In Asymmetric encryption, you have two keys. These are:

1. Public key.
2. Private key.


The client/user/browser gives the public key to the server with which they are communicating. Then, the encyption happens with the help of the public key, and the decryption happens with the help of the server's private key.

The private key can only be found on that particular server. No one else has it. This shows you why asymmetric encryption is stronger and tougher to hack, because it has two different keys, the private and public key. The two keys work together to make sure the data is more secure.

This also tells you why the size of this encryption is 1024/2048 bits.

What is symmetric encryption?

In symmetric encryption, it's very simple. You have one key, and that's it. The client uses one key for encryption, and the server uses the same key for decrypting the data.

Symmetric encryption is very light weight. The size is 128/256 bits. But it is a bit easier to hack into as compared to asymmetric. This doesn't mean it is not useful. When we use SSL, we combine Asymmetric and Symmetric to be able to make the communication safer and more secure.


How asymmetric + symmetric encryption work

The combination of both asymmetric and symmetric is now the double-sided wall. 

In the first step, the server will send to the browser the asymmetric public key. As we now know, the asymmetric key has both the public key and the private key. Therefore, the browser will receive the public key.

After this, the browser generates a session key.

Symmetric encryption uses only one single key for both the client and the server. So what will happen is, the browser will generate a local session key. This is a symmetric encryption session key. It will then encrypt it, with the use of the public key which is asymmetric, given in the first step. The locally generated session key will then be combined with the public key, and sent to the server.

The server will then use a private key to decrypt the encrypted session key it has received. In this particular step, the server will use asymmetric private key to decrypt the session key it has received.

Now, once the decryption has happened, the server and the browser will use the session key for communication. The session key will only be used for that specific session.

Let's say you close your browser, and maybe sign in the next day – everything starts all over again. Session keys get created again.

How Can I Get SSL for My Website?

If you are a website owner, you can acquire an SSL certificate from a certificate issuing authority.

You will then need to install the certificate on you web server where your website is hosted. Most of the time, the hosting company where you host your website handles this process for you.

Where Can I Get an SSL Certificate?

There are organizations that issue security certificates. These organizations are called certificate authorities. Some of these certificate authorities include: DigiCert, Comodo, and many others.

Many developers get certificates from these organizations. Since they are the most widely used certificate issuers, browsers usually trust certificates from these organizations.

Can I Get an SSL Certificate for Free?

Cloudflare offers SSL certificates for free. It is one of the first internet security companies to do so.

If you want to get one, you can check it out here.

What is HTTPS Used For?

HTTPS helps a lot with security. Without it, passing sensitive information becomes a big challenge especially if your business requires a secure way of communication.

Sites that accept online payments like ecommerce sites typically require HTTPS. This is to avoid information such as credit card details and login information from being stolen (Source: Tony Messer).

The Main Differences between HTTPS and HTTP

• The encryption layer is enabled in HTTPS while there is no encryption layer in HTTP.
• Your data is protected in HTTPS while in HTTP it is not.
• Your ranking is boosted in Google when you use HTTPS while with HTTP, you don't get any ranking boost.
• You are protected against phishing when you use HTTPS while there is not protection when using HTTP.
• You are compliant with the regulations of the payment industry when you use HTTPS while HTTP is non-compliant.
• Loading HTTPS in the first few seconds may be slower than loading HTTP.
• Getting SSL certificates can cost money while there is no certification costs with HTTP.
• While using HTTPS, you become buddies with Google Chrome. Google Chrome doesn't like HTTP and therefore you will always be getting unsecured site notifications.

Conclusion

HTTP and HTTPS are very important in our day to day lives as developers. The communication between the browser and the server is what fuels much the work we do.

By protecting your users' data as much as you're able so their information doesn't get stolen, you'll gain their trust and provide a better user experience.

See you soon.

Why Use Rate Limiting?

Let's get started with some basics to make sure we understand the need for rate limiting and introduce the tools we'll be using in this tutorial.

Problem with Unlimited Rates

If a public API like the Twitter API allowed its users to make an unlimited number of requests per hour, it could lead to:

• resource exhaustion
• decreasing quality of the service
• denial of service attacks

This might result in a situation where the service is unavailable or slow. It could also lead to more unexpected costs being incurred by the service.

How Rate Limiting Helps

Firstly, rate-limiting can prevent denial of service attacks. When coupled with a deduplication mechanism or API keys, rate limiting can also help prevent distributed denial of service attacks.

Secondly, it helps in estimating traffic. This is very important for public APIs. This can also be coupled with automated scripts to monitor and scale the service.

And thirdly, you can use it to implement tier-based pricing. This type of pricing model means that users can pay for a higher rate of requests. The Twitter API is an example of this.

The Token Bucket Algorithm

Token Bucket is an algorithm that you can use to implement rate limiting. In short, it works as follows:

1. A bucket is created with a certain capacity (number of tokens).
2. When a request comes in, the bucket is checked. If there is enough capacity, the request is allowed to proceed. Otherwise, the request is denied.
3. When a request is allowed, the capacity is reduced.
4. After a certain amount of time, the capacity is replenished.

How to Implement Token Bucket in a Distributed System

To implement the token bucket algorithm in a distributed system, we need to use a distributed cache.

The cache is a key-value store to store the bucket information. We will use a Redis cache to implement this.

Internally, Bucket4j allows us to plug in any implementation of the Java JCache API. The Redisson client of Redis is the implementation we will use.

Project Implementation

We will use the Spring Boot framework to build our service.

Our service will contain the below components:

1. A simple REST API.
2. A Redis cache connected to the service – using the Redisson client.
3. The Bucket4J library wrapped around the REST API.
4. We'll connect Bucket4J to the JCache interface which will use the Redisson client as the implementation in the background.

First, we will learn to rate limit the API for all requests. Then we will learn to implement a more complex rate limiting mechanism per user or per pricing tier.

Let's start with the project setup.

Install Dependencies

Let's add the below dependencies to our pom.xml (or build.gradle) file.

<dependencies>
    <!-- To build the Rest API -->
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <!-- Redisson Starter = Spring Data Redis starter(excluding other clients) and Redisson client -->
    <dependency>
        <groupId>org.redisson</groupId>
        <artifactId>redisson-spring-boot-starter</artifactId>
        <version>3.17.0</version>
    </dependency>

    <!-- Bucket4J starter = Bucket4J + JCache -->
    <dependency>
        <groupId>com.giffing.bucket4j.spring.boot.starter</groupId>
        <artifactId>bucket4j-spring-boot-starter</artifactId>
        <version>0.5.2</version>
    </dependency>
</dependencies>

Cache Configuration

Firstly, we need to start our Redis server. Let's say we have a Redis server running on port 6379 on our local machine.

We need to perform two steps:

1. Create a connection to this server from our application.
2. Set up JCache to use the Redisson client as the implementation.

Redisson's documentation provides concise steps to implement this in a regular Java application. We're going to implement the same steps, but in Spring Boot.

Let's look at the code first. We need to create a Configuration class to create the required beans.

@Configuration
public class RedisConfig  {

    @Bean
    public Config config() {
        Config config = new Config();
        config.useSingleServer().setAddress("redis://localhost:6379");
        return config;
    }

    @Bean
    public CacheManager cacheManager(Config config) {
        CacheManager manager = Caching.getCachingProvider().getCacheManager();
        cacheManager.createCache("cache", RedissonConfiguration.fromConfig(config));
        return cacheManager;
    }

    @Bean
    ProxyManager<String> proxyManager(CacheManager cacheManager) {
        return new JCacheProxyManager<>(cacheManager.getCache("cache"));
    }
}

What does this do?

1. Creates a configuration object that we can use to create a connection.
2. Creates a cache manager using the configuration object. This will internally create a connection to the Redis instance and create a hash called "cache" on it.
3. Creates a proxy manager that will be used to access the cache. Whatever our application tries to cache using the JCache API, it will be cached on the Redis instance inside the hash named "cache".

Build the API

Let's create a simple REST API.

@RestController
public class RateLimitController {
    @GetMapping("/user/{id}")
    public String getInfo(@PathVariable("id") String id) {
        return "Hello " + id;
    }
}

If I hit the API with the URL http://localhost:8080/user/1, I will get the response Hello 1.

Bucket4J Configuration

To implement the rate limiting, we need to configure Bucket4J. Thankfully, we do not need to write any boilerplate code due to the starter library.

It also automatically detects the ProxyManager bean we created in the previous step and uses it to cache the buckets.

What we do need to do is configure this library around the API we created.
Again there are multiple ways to do this.

We can go for property-based configuration which is defined in the starter library.
This is the most convenient way for simple cases like rate-limiting for all users or all guest users.

However, if we want to implement something more complex like a rate limit for each user, it's better to write custom code for it.

We are going to implement rate limiting per user. Let's assume we have the rate limit for each user stored in a database, and we can query it using the user id.

Let's write the code for it step by step.

Create a Bucket

Before we start, let's look at how a bucket is created.

Refill refill = Refill.intervally(10, Duration.ofMinutes(1));
Bandwidth limit = Bandwidth.classic(10, refill);
Bucket bucket = Bucket4j.builder()
        .addLimit(limit)
        .build();

• Refill – After how much time the bucket will be refilled.
• Bandwidth – How much bandwidth the bucket has. Basically, requests per refill period.
• Bucket – An object configured using these two parameters. Additionally, it maintains a token counter to keep track of how many tokens are available in the bucket.

Using this as the building block, let's change a few things to make it suitable to our use case.

Create and Cache Buckets using ProxyManager

We created the proxy manager for the purpose of storing buckets on Redis. Once a bucket is created, it needs to be cached on Redis and does not need to be created again.

To make this happen, we will replace the Bucket4j.builder() with proxyManager.builder(). ProxyManager will take care of caching the buckets and not creating them again.

ProxyManager's builder takes two parameters – a key against which the bucket will be cached and a configuration object that it will use to create the bucket.

Let's see how we can implement it:

@Service
public class RateLimiter {
    //autowiring dependencies

    public Bucket resolveBucket(String key) {
        Supplier<BucketConfiguration> configSupplier = getConfigSupplierForUser(key);

        // Does not always create a new bucket, but instead returns the existing one if it exists.
        return buckets.builder().build(key, configSupplier);
    }

    private Supplier<BucketConfiguration> getConfigSupplierForUser(String key) {
        User user = userRepository.findById(userId);
        Refill refill = Refill.intervally(user.getLimit(), Duration.ofMinutes(1));
        Bandwidth limit = Bandwidth.classic(user.getLimit(), refill);
        return () -> (BucketConfiguration.builder()
                .addLimit(limit)
                .build());
    }
}

We have created a method which returns a bucket for a key provided. In the next step, we will see how to use this.

How to Consume Tokens and Set Up Rate Limiting

When a request comes in, we will try to consume a token from the relevant bucket.
We will use the tryConsume() method of the bucket to do this.

@GetMapping("/user/{id}")
public String getInfo(@PathVariable("id") String id) {
    // gets the bucket for the user
    Bucket bucket = rateLimiter.resolveBucket(id);

    // tries to consume a token from the bucket
    if (bucket.tryConsume(1)) {
        return "Hello " + id;
    } else {
        return "Rate limit exceeded";
    }
}

The tryConsume() method returns true if the token was consumed successfully or false if the token was not consumed.

How to Test our Service

We can test this using any automated testing technique. For example, we can use JUnit. Let's write a test case that calls the getInfo() method multiple times and verifies that the response is correct.

Let's assume we have a user with id 1 and a limit of 10 requests per minute. Let's assume we also have a user with id 2 and a limit of 20 requests per minute.

We will hit 11 requests for both users and verify that the request fails for the user with id 1 but succeeds for the user with id 2.

@Test
public void testGetInfo() {

    // calls the method 10 times for user 1
    for (int i = 0; i < 10; i++) {
        rateLimiter.getInfo(1));
        rateLimiter.getInfo(2));
    }

    // verifies that the response is rate limited for user 1
    assertEquals("Rate limit exceeded", rateLimiter.getInfo(1));

    // verifies that the response is successful for user 2
    assertEquals("Hello 2", rateLimiter.getInfo(2));
}

When we run the test, we will see that the test passes.

Conclusion

In this tutorial, we have covered how to create a rate limiter using Bucket4j and Redis in a Spring Boot application.We also looked at how to set up a Redisson client with JCache and how to use it to cache buckets.

At the end, we implemented a simple rate limiter which can be used to rate limit requests for specific users.

Hope you enjoyed this tutorial. Thanks for reading!

In this tutorial, we will learn how to create a server. We will begin without express and then strengthen the server using express. After that, we will see how to upload images to Cloudinary from the app we have created.

I assume that you already understand the basics of Node.js, express and nodemon so we will just go straight to the practical parts.

Install Node.js and NPM

If you haven't yet done so, you'll need to install Node and npm on your machine.

1. Go to the Node.js website
2. Click on the recommended download button

Nodejs home page

When the download is complete, install Node using the downloaded .exe file (it follows the normal installation process).

Check if the installation was successful

1. Go to your terminal/command prompt (run as administrator if possible)
2. Type in each of the following commands and hit Enter

node -v 
npm -v

Your output should be similar to the image below:

Terminal showing the versions of node and npm

The version may be different but that's OK.

How to Create a Node Server without Express

For the rest of this tutorial, I will be using VS code as my editor. You can use whatever editor you choose.

Let's start by creating a project directory. Open a terminal and type the following to create a directory and open it:

mkdir server-tutorial cd server-tutorial

I named my project directory server-tutorial, but you can name yours as you please.

In the terminal, type npm init. Hit the Enter button for all prompts. When completed, you should have a package.json file seated in your project directory.

The package.json file is just a file with all the details of your project. You don't have to open it.

Create a file called index.js.

In the file, require the HTTP module like so:

  const http = require('http');

Call the createServer() method on it and assign it to a constant like this:

  const server = http.createServer();

Call the listen() method on the server constant like this:

  server.listen();

Give it a port to listen to. Now this could be any free port, but we will be using port 3000 which is the conventional port. So we have this:

  const http = require('http');

  const server = http.createServer();

  server.listen(3000);

Basically, that is all you need do to create a server.

How to Test the Server

In your terminal (should be in the project directory), type node index.js and hit the Enter button.

Open a new tab in postman or any web browser and in the address bar, type http://localhost:3000/, and hit the Enter button. (I will be using postman because of its extended functionality outside the box.)

You will notice that your browser or postman keeps loading indefinitely like so:

Yay! That is fine. Our Server is up and running.

But it's boring already. We need to make the server talk to us.

Let's get to it immediately.

How to Send Back a Response from the Server

Back in the code, add the following to const server = http.createServer();:

 (request, response) => {
    response.end('Hey! This is your server response!');
 }

So we now have:

  const http = require('http');

  const server = http.createServer((request, response) => {
    response.end('Hey! This is your server response!');
  });

server.listen(3000);

In basic terms, the request object tells the server that we want something, the response object tells us what the server has to say about our request, and the end() method terminates the communication with the server response.

Hopefully, that makes sense!

Now, test the server again following the steps we outlined above and your server should be talking to you. This is my output:

Feel free to change the string as you wish.

Use Control/Command + C to terminate the server and run node index to start the server again.

Looking Sharp! Right? All good...

How to Create a Node Server With Express

In this section, we want to make our lives easier by using Express and Nodemon (node-mon or no-demon, pronounce it as you wish).

In the terminal, install the following:

npm install express --save 
npm install nodemon --save-dev

Create a new file named app.js or whatever suits you

In the file,

1. Require express like so:

const express = require('express');

2. Assign the express method to a constant like this:

const app = express();

3. Export the app constant to make it available for use in other files within the directory like so:

module.exports = app;

So we have:

const express = require('express');

const app = express();



module.exports = app;

In the index.js file, require the app we exported a while ago:

const app = require('./app');

Next, set the port using the app like so:

app.set('port', 3000);

And replace the code in the http.createServer() method with just app like this:

const server = http.createServer(app);

This directs all API management to the app.js file helping with separation of concerns.

So our index.js file now looks like this:

const http = require('http');
const app = require('./app');

app.set('port', 3000);
const server = http.createServer(app);

server.listen(3000);

Back in our app.js file, since we have directed all API management to it, let's create an endpoint to speak to us like before.

So before the module.exports = app, add the following code:

app.use((request, response) => {
   response.json({ message: 'Hey! This is your server response!' }); 
});

We now have:

const express = require('express');

const app = express();

app.use((request, response) => {
   response.json({ message: 'Hey! This is your server response!' }); 
});

module.exports = app;

Ahaaa... It's time to test our app.

To test our app, we now type nodemon index in our terminal and hit the Enter button. This is my terminal:

Do you notice that nodemon gives us details of execution in the terminal unlike Node? That's the beauty of nodemon.

You can now go to postman or any browser and in the address bar, type http://localhost:3000/ and hit Enter. See my output:

Walah! It's working.

Now more reasons to use nodemon. Go to the app.js file and change the message string to any string on your choice, save, and watch the terminal.

Wow... It automatically restarts the server. This was impossible with Node. We had to restart the server ourselves.

How to Secure the Server and Make it Future-Proof

In the index.js file, replace all the code with the following:

const http = require('http');
const app = require('./app');

const normalizePort = val => {
  const port = parseInt(val, 10);

  if (isNaN(port)) {
    return val;
  }
  if (port >= 0) {
    return port;
  }
  return false;
};
const port = normalizePort(process.env.PORT || '3000');
app.set('port', port);

const errorHandler = error => {
  if (error.syscall !== 'listen') {
    throw error;
  }
  const address = server.address();
  const bind = typeof address === 'string' ? 'pipe ' + address : 'port: ' + port;
  switch (error.code) {
    case 'EACCES':
      console.error(bind + ' requires elevated privileges.');
      process.exit(1);
      break;
    case 'EADDRINUSE':
      console.error(bind + ' is already in use.');
      process.exit(1);
      break;
    default:
      throw error;
  }
};

const server = http.createServer(app);

server.on('error', errorHandler);
server.on('listening', () => {
  const address = server.address();
  const bind = typeof address === 'string' ? 'pipe ' + address : 'port ' + port;
  console.log('Listening on ' + bind);
});

server.listen(port);

process.env.PORT makes the app dynamic so that it can run any port assigned to it in the future when hosted on a live server.

The normalizePort function returns a valid port, whether it is provided as a number or a string.

The errorHandler function checks for various errors and handles them appropriately — it is then registered to the server.

A listening event listener is also registered, logging the port or named pipe on which the server is running to the console.

YooH! Our server is more secure and robust right now. Notice that nodemon also displays the port we are listening on.

There you have it, a simple, secure and robust Node.js server.

How to Upload Images to Cloudinary

Now that we have a cool server running, let's learn how we can save our images on Cloudinary. This will just be a basic introduction so it should be fun 😊.

Cloudinary helps developers across the world manage images with minimal effort.

How to Create a Cloudinary Account

To create an account, go to the Cloudinary Website.

1. Click the sign up button on the top right.
2. Fill the form that shows up accordingly.
3. Submit the form using the Create Account button.
4. Check your email to finish up by validating your email

You should be able to access your dashboard which looks like mine below:

Notice the Account details. You shouldn't reveal this information to anyone. I am showing it to you here because this is a temporary account that I'm using only for the purposes of this tutorial.

Checkout the Media Library tab too. This is where the uploaded images will appear.

If you have all these showing, then let's rock and roll...

How to Install Cloudinary in Our Project

Open your terminal and navigate into the project directory.

Execute the following command to install Cloudinary:

  npm install cloudinary --save

How to Setup Cloudinary in Our Project

In the app.js file, require cloudinary below the const app = express(); like so:

  const cloudinary = require('cloudinary').v2

Next, add the configuration details from the account details on your dashboard like this:

    cloud_name: 'place your cloud_name here',
    api_key: 'place your api_key here',
    api_secret: 'place your api_secret here',

This is what I have:

  // cloudinary configuration
  cloudinary.config({
    cloud_name: "dunksyqjj",
    api_key: "173989938887513",
    api_secret: "ZPLqvCzRu55MaM1rt-wxJCmkxqU"
  });

How to Create an EndPoint to Upload an Image

To avoid bugs in our code, first replace the existing API with the following code:

  app.get("/", (request, response) => {
    response.json({ message: "Hey! This is your server response!" });
  });

It is basically the same but this time, we are using the get verb in place of the use verb and we added a root end-point (/).

Next, just before the module.exports = app; line, we will be creating our image-upload API.

Let's start by placing this code there:

// image upload API
app.post("/upload-image", (request, response) => {});

Basically, this is how we set up an API. The API makes a POST request to the server telling the server that the request should be handled with a degree of security. It uses two parameters to make this request: an end-point (/upload-image) and a callback function ((request, response) => {}).

Let's breathe life into the API by building out the callback function.

How to Build the Callback Function

Install body-parser

This npm package enables us to handle incoming requests using req.body or request.body as the case may be. We will be installing body-parser using the following code:

  npm install --save body-parser

Configure body-paser for our project

Require body-parse in the app.js like so:

const bodyParser = require('body-parser');

Next, add the following code to set its json function as global middleware for our app like so:

  app.use(bodyParser.json());
  app.use(bodyParser.urlencoded({ extended: true }));

We can now handle our request body appropriately.

Back to Building Our Function

In the function, add the following code to collect any data (images) entered by a user:

    // collected image from a user
    const data = {
        image: request.body.image,
    };

Next, upload the image to cloudinary using the following code:

cloudinary.uploader.upload(data.image);

Basically, this is all we need to upload our image. So our app.js looks like this:

const express = require("express");
const app = express();
const cloudinary = require("cloudinary").v2;
const bodyParser = require('body-parser');

// body parser configuration
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

// cloudinary configuration
cloudinary.config({
  cloud_name: "dunksyqjj",
  api_key: "173989938887513",
  api_secret: "ZPLqvCzRu55MaM1rt-wxJCmkxqU"
});

app.get("/", (request, response) => {
  response.json({ message: "Hey! This is your server response!" });
});

// image upload API
app.post("/image-upload", (request, response) => {
    // collected image from a user
    const data = {
      image: request.body.image,
    }

    // upload image here
    cloudinary.uploader.upload(data.image);

});

module.exports = app;

Now this looks good and it works perfectly. You can test it out using postman. But it's would be awesome if our app could give us feedback when it's done handling our requests, right?

To make this happen, we will add the following then...catch... block to the cloudinary upload like so:

    // upload image here
    cloudinary.uploader.upload(data.image)
    .then((result) => {
      response.status(200).send({
        message: "success",
        result,
      });
    }).catch((error) => {
      response.status(500).send({
        message: "failure",
        error,
      });
    });

So our final code will be:

const express = require("express");
const app = express();
const cloudinary = require("cloudinary").v2;
const bodyParser = require('body-parser');

// body parser configuration
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

// cloudinary configuration
cloudinary.config({
  cloud_name: "dunksyqjj",
  api_key: "173989938887513",
  api_secret: "ZPLqvCzRu55MaM1rt-wxJCmkxqU"
});

app.get("/", (request, response) => {
  response.json({ message: "Hey! This is your server response!" });
});

// image upload API
app.post("/image-upload", (request, response) => {
    // collected image from a user
    const data = {
      image: request.body.image,
    }

    // upload image here
    cloudinary.uploader.upload(data.image)
    .then((result) => {
      response.status(200).send({
        message: "success",
        result,
      });
    }).catch((error) => {
      response.status(500).send({
        message: "failure",
        error,
      });
    });

});

module.exports = app;

How to Test our API

Create a folder/directory in the root directory and name it images like so:

  mkdir images

Copy an image of your choice to this folder. (Now, the path to your image relative to the app.js file should look like this: "images/<your-image.jpg">.)

Now let's proceed to postman.

1. In the address bar, enter this: http://localhost:3000/image-upload
2. Set the Header Key to Content-Type and value to application/json
3. Set the body to the json data we declared in our code like so:

       {
       "image": "images/oskar-yildiz-gy08FXeM2L4-unsplash.jpg"
       }

Hit the Send button and wait for the upload to complete and get your response:

Now, this is the result. The image now has a unique public_id which is randomly generated by Cloudinary and a secure_url which is globally accessible (you can load it in your browser to see).

Finally, checking the Media Library tab on your Cloudinary dashboard, you should have a new image with a new badge on it. This will have a unique id that matches the public_id we saw in the postman result above just like in the image below:

Walah! We are persisting images without stress...That feels good.

Well, one more thing – SECURITY!

Our Cloudinary configuration details rea exposed in our app.js file. If we push our project to GitHub, it becomes publicly available to anyone who cares to check it out. And that becomes a problem if it gets into the wrong hands.

But don't worry about a thing here, there is a fix for almost everything in this space. We will be using the dotenv npm package to hid our configurations from the public.

How to Secure Our Configurations with dotenv

First, you'll need to install dotenv if you haven't already:

npm install dotenv --save

Then require dotenv in app.js like so:

  require('dotenv').config()

Create a new file in the root directory and name it .env.

In the file, enter your Cloudinary configuration details like so:

  CLOUD_NAME=dunksyqjj
  API_KEY=173989938887513
  API_SECRET=ZPLqvCzRu55MaM1rt-wxJCmkxqU

In the app.js file, we will access the configurations in the .env file via the process.env property like so:

// cloudinary configuration
cloudinary.config({
  cloud_name: process.env.CLOUD_NAME,
  api_key: process.env.API_KEY,
  api_secret: process.env.API_SECRET
});

This is my app.js code at the moment:

const express = require("express");
const app = express();
const cloudinary = require("cloudinary").v2;
const bodyParser = require('body-parser');
require('dotenv').config()

// body parser configuration
app.use(bodyParser.json());
  app.use(bodyParser.urlencoded({ extended: true }));

// cloudinary configuration
cloudinary.config({
  cloud_name: process.env.CLOUD_NAME,
  api_key: process.env.API_KEY,
  api_secret: process.env.API_SECRET
});

app.get("/", (request, response, next) => {
  response.json({ message: "Hey! This is your server response!" });
  next();
});

// image upload API
app.post("/image-upload", (request, response) => {
    // collected image from a user
    const data = {
      image: request.body.image,
    }

    // upload image here
    cloudinary.uploader.upload(data.image)
    .then((result) => {
      response.status(200).send({
        message: "success",
        result,
      });
    }).catch((error) => {
      response.status(500).send({
        message: "failure",
        error,
      });
    });
});

module.exports = app;

Let's test our app again to make sure that nothing is broken. Here is my result:

I now have two of the same image but with different public_ids.

And that is it!

Yeeeh! Our application is more secure than it was when we started.

Conclusion

In this tutorial, we went through the steps involved in creating a server using just Node.js. And after that, we improved our server using Express and nodemon.

Finally, we saw how to upload an image to Cloudinary through our Express application and how our configuration details are secured using the dotenv package.

This is just an introduction. You can do a whole lot more if you play around with this application.

You can find the server creation code here.

And the image upload codes are available here.

Thank you for your time. 😊

What is reCaptcha?

reCaptcha is a Google service provided for free that helps you protect your websites from spam and malicious attacks.

The new version, V3, has many improvements over previous versions thanks to the new captcha challenges. It returns a score and analytics you can use to take appropriate action for your website.

Here's what the previous version of reCaptcha looks like – but as of the latest release (v3), reCaptcha has changed a lot and has a better user experience.

Previous reCaptcha Version

Previous reCaptcha Version

What you'll learn

By the end of this article, you'll have learned the following:

1. How to integrate the reCaptcha v3 into your Laravel project
2. How to setup a Google reCaptcha admin dashboard
3. How to view your website reCaptcha scores and analytics to help you make better security decisions

How to Setup reCaptcha in a Laravel Project

You can follow these simple steps to get reCaptcha set up on your project.

1. Install this laravel project if you haven't done so yet
2. In the terminal, pull the open-source package into your project with composer.

composer require biscolab/laravel-recaptcha

3. Publish the recaptcha.php with this command:

php artisan vendor:publish --provider="Biscolab\ReCaptcha\ReCaptchaServiceProvider"

This will create a file in the config directory, called config\recaptcha.php, where we will add more reCaptcha configurations.

4. Visit this link to create a reCaptcha admin account for yourself.

Register reCaptcha v3

To create the reCaptcha admin, you can do the following:

• Add your site name to the label – localhost or examplesite.com
• Select v3 as the reCaptcha type
• Include domains in the domain section (localhost or examplesite.com)
• Add the owner's email address to the owner's section
• Check the "accept terms and service" box

Just a note – the localhost is for the sole purpose of developing locally. As such, it should be updated before moving to a production environment.

5. Add the reCaptcha to your site

Click the submit button and save your secret keys.

Adding reCaptcha to your site within the .env

6. Add the site keys to the .env file of your project:

RECAPTCHA_SITE_KEY=ADD_YOUR_SITE_KEY
RECAPTCHA_SECRET_KEY=ADD_YOUR_SECRET_KEY
RECAPTCHA_SITE=https://www.google.com/recaptcha/admin/

Since you have made changes to the .env, it's best to clear all cached configurations so that the new changes take effect. Use php artisan optimize:clear in your terminal.

7. Within the config > recaptcha.php file, update the property of the version to V3. It's also important to note that the api_site_key and api_secret_key generated via the admin dashboard will be referenced from what we set in the .env file of the project.

return [
    'version'                      => 'v3'
]

You can now head over to the analytics page of the reCaptcha admin to view how well your site is performing, view your scores, and make decisions when you're in a production environment.

reCaptcha analytics page

The below image shows that reCaptcha has been implemented.

Conclusion

At the end of this article, I hope you'll find it easier to set up reCaptcha and that you'll have a better understanding of what it's all about. Now you should be able to set up the most recent version within your Laravel project.

Resources

• What is reCaptcha?
• Laravel reCaptcha repo
• Laravel reCaptcha docs