
![Image](/pub-sub-architecture-thumbnail.png)

In this project, I used HiveMQ's public MQTT broker to send messages from a Next.js component to an I2C LCD display connected to an Arduino Uno with an Ethernet shield. This setup allows real-time message updates on the LCD using the MQTT protocol.

## Understanding Pub/Sub Architecture

The **Publish-Subscribe (Pub/Sub)** architecture is a messaging pattern where senders (publishers) and receivers (subscribers) communicate through an intermediary called a **broker**. Publishers send messages to topics, and subscribers listening to those topics receive the messages.

### Real-World Examples of Pub/Sub

- **Smart Home Systems**: A smart home app can publish commands like "turn on lights" to an MQTT broker, and all subscribed smart devices will act accordingly.
- **Stock Market Feeds**: Financial platforms use pub/sub to distribute stock updates in real time to multiple users.
- **Chat Applications**: Messaging apps use MQTT to push messages instantly to users subscribed to a particular chat room.

	![Image](/pub-sub-diagram.png)

## Next.js Component to Publish Messages

In the Next.js app, we send messages to HiveMQ's broker. Here’s the core function responsible for publishing messages:

```tsx
const sendMessage = async (msg: string) => {
  try {
    const res = await fetch("/api/proxy", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ message: msg }),
    });

    if (!res.ok) throw new Error(`Error: ${res.status}`);
  } catch (error) {
    console.error("Failed to send message", error);
  }
};
```

This function sends a message to our backend, which then forwards it to HiveMQ’s broker.

## Arduino Code to Subscribe and Display Messages

On the Arduino side, the device listens for MQTT messages and displays them on an I2C LCD. The key snippet for handling incoming messages is:

```cpp
void setup() {
    client.setServer(mqttServer, mqttPort);
    client.setCallback(callback);
    client.subscribe(mqttTopic); // Subscribe to the topic
}

void callback(char* topic, byte* payload, unsigned int length) {
    String message = "";
    for (unsigned int i = 0; i < length; i++) {
        message += (char)payload[i];
    }
    lcd.clear();
    lcd.setCursor(0, 0);
    lcd.print(message.substring(0, 20)); // Display first 20 characters
}
```

This function extracts the message content and prints it on the LCD display. The `setup` function ensures that the Arduino subscribes to the correct MQTT topic to receive updates.

## Conclusion

By leveraging HiveMQ’s public broker, we achieved real-time communication between a Next.js web app and an Arduino LCD display. This project demonstrates the power of MQTT and pub/sub architecture for IoT applications.

![image](/micro-controller.jpg)

Visit the [Micro-controllers](https://tauseef.dev/microcontrollers 'Micro-controllers') page to send me a message and see how it would appear on the I2C screen with the animated demo screen!

Let me know if you have any questions or suggestions!



Using HiveMQ MQTT Public Broker to Control an I2C LCD from Next.js


![Image](/cross-site-scripting.png)

After an annual round of penetration testing at the company I work for, the web application was found to be vulnerable to a Stored Cross-Site Scripting (XSS) attack.

## Understanding Stored XSS

A Stored Cross-Site Scripting (XSS) attack occurs when a web application accepts user input, stores it on the server, and later displays it on a webpage without proper sanitisation, allowing malicious scripts to execute in a victim's browser. This differs from Reflected XSS, where the payload is not stored but rather executed immediately when the malicious link is clicked.

To test for this vulnerability, we used PortSwigger's HTTP traffic interceptor, [Burp Proxy](https://portswigger.net/burp/documentation/desktop/tools/proxy 'Burp Proxy'). This allowed us to intercept the request, inject a malicious script into a parameter, and observe its execution when the data was rendered on the web page.

## Example Payloads

Consider the `streetAddress` parameter, which is sent to the server as part of an HTTP POST request:

**Before Injection:**
```html
<input type="hidden" name="streetAddress" value="10 Example Street">
```

**After Injection:**
```html
<input type="hidden" name="streetAddress" value="10 Example Street"><script>alert('XSS');</script>">
```

In this example, the injected script executes a simple `alert('XSS')`, demonstrating the potential for arbitrary JavaScript execution. A real attacker could replace this with a script to steal session cookies, perform keylogging, or carry out other malicious actions.

## The Solution

Mitigating Stored XSS requires a multi-layered approach involving **input validation, output encoding, and security headers**.

### 1. Input Validation
Input validation ensures that only expected characters are allowed in user inputs. Where possible, use **whitelisting** or **regular expressions (regex)** to enforce constraints. For example, an account number field should only permit numeric characters.

### 2. Output Encoding (Primary Defence)
Output encoding ensures that special characters are displayed as plain text rather than executed as code. This should be implemented according to the context:
- **HTML Encoding:** Convert `<script>` into `&lt;script&gt;`.
- **JavaScript Encoding:** Escape quotes and special characters.
- **Attribute Encoding:** Prevent breaking out of attributes.

### 3. Secure Coding Implementation
We used the [Validator](https://www.npmjs.com/package/validator 'Validator') library to sanitise input, escaping special characters using `.escape()`, as shown below:

```javascript
const { streetAddress, city } = req.body;
const validator = require('validator');

let sanitizedAddress = streetAddress ? validator.escape(streetAddress) : streetAddress;
let sanitizedCity = city ? validator.escape(city) : city;

if ((sanitizedAddress !== streetAddress) || (sanitizedCity !== city)) {
  return reject(new Error("Unable to update details due to sanitisation error."));
}

req.body.street = sanitizedAddress || streetAddress;
```

This ensures that special characters such as `<, >, &, ', " and /` are escaped before storage, preventing execution when displayed.

### 4. Additional Security Best Practices
#### **Use a Content Security Policy (CSP)**
A strong **Content Security Policy (CSP)** header can prevent the execution of inline scripts:
```http
Content-Security-Policy: default-src 'self'; script-src 'self'
```

#### **Set HTTPOnly and Secure Flags on Cookies**
This prevents scripts from accessing cookies, reducing the risk of session hijacking:
```http
Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Strict
```

## Conclusion
By implementing **input validation, output encoding, and security headers**, we effectively mitigated the risk of Stored XSS in our application. While validation is a good first step, output encoding remains the **primary defence** against XSS. Additionally, adopting **CSP and secure cookie settings** further hardens the application's security against such attacks.

Get in touch if you have any feedback or questions!


Stored Cross-Site-Scripting (XSS)


![image](/cache-rules-thumbnail.png)

Caching is an essential optimization strategy in web development, especially for high-performance applications built with Next.js. It reduces redundant computations, improves response times, and enhances scalability. Next.js provides multiple caching mechanisms, each suited to different use cases. In this blog post, we'll explore various caching options in Next.js, including in-memory caching, `getStaticProps`, Redis, and more, discussing their pros and cons to help you choose the right approach for your application.


## Why Caching Matters

Caching enhances performance by storing frequently accessed data, reducing the need to fetch or compute it repeatedly. Key benefits include:

- **Faster Load Times**: Cached content loads instantly, reducing latency.
- **Reduced Server Load**: Fewer API/database calls mean lower resource consumption.
- **Improved Scalability**: Cached responses prevent servers from being overwhelmed.
- **Better User Experience**: Faster responses lead to better engagement and satisfaction.


## Caching Options in Next.js

### 1. **In-Memory Caching**

In-memory caching stores data within the application's server runtime, making it a fast option for frequently accessed data.

#### **Implementation Example:**
```javascript
const cache = new Map();

export async function fetchWithCache(key, fetcher) {
  if (cache.has(key)) {
    return cache.get(key);
  }
  const data = await fetcher();
  cache.set(key, data);
  return data;
}
```

#### **Pros:**
- Extremely fast since data is stored in memory.
- No additional infrastructure required.

#### **Cons:**
- Not persistent across deployments (data is lost on restart).
- Limited scalability in a serverless environment.

**Best For:**
- Caching frequently used computations in API routes.
- Temporary storage in a long-running Next.js server.


### 2. **getStaticProps (Static Generation)**

`getStaticProps` pre-renders pages at build time, storing the generated HTML for subsequent requests.

#### **Implementation Example:**
```javascript
export async function getStaticProps() {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();

  return {
    props: { data },
    revalidate: 60, // Re-generate page every 60 seconds
  };
}
```

#### **Pros:**
- Best performance as pages are served statically.
- Great for SEO since the content is pre-rendered.
- Reduces database/API load significantly.

#### **Cons:**
- Data is not always up-to-date unless revalidated (`revalidate` option in ISR).
- Not suitable for dynamic user-generated content.

**Best For:**
- Blogs, marketing pages, and documentation sites.
- Any content that updates infrequently.


### 3. **Incremental Static Regeneration (ISR)**

ISR allows static pages to be regenerated in the background while still serving stale data until the new data is ready.

#### **Pros:**
- Combines static generation performance with dynamic data fetching.
- Useful when data updates at regular intervals without requiring real-time updates.

#### **Cons:**
- Still not real-time; updates depend on the `revalidate` period.

**Best For:**
- Product catalogs, listings, and dashboards where updates happen periodically.


### 4. **Server-Side Rendering (SSR) with Caching**

Next.js supports SSR via `getServerSideProps`, but caching the responses can improve performance.

#### **Implementation Example (Using Vercel's Edge Cache):**
```javascript
export async function getServerSideProps(context) {
  const res = await fetch('https://api.example.com/data', {
    headers: { 'Cache-Control': 's-maxage=60, stale-while-revalidate' },
  });
  const data = await res.json();

  return { props: { data } };
}
```

#### **Pros:**
- Ensures users always see fresh data.
- Can be combined with Edge caching (e.g., Vercel) for better performance.

#### **Cons:**
- Slower than static generation as it runs on every request.
- Increased server costs if not cached properly.

**Best For:**
- Personalized content that must be fresh on every request.
- Applications with user authentication.


### 5. **Redis Caching**

Redis is an external in-memory database optimized for caching frequently accessed data.

#### **Implementation Example:**
```javascript
import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL);

export async function fetchWithRedisCache(key, fetcher) {
  const cachedData = await redis.get(key);
  if (cachedData) return JSON.parse(cachedData);

  const data = await fetcher();
  await redis.set(key, JSON.stringify(data), 'EX', 60); // Cache for 60s
  return data;
}
```

#### **Pros:**
- Persistent and shareable across deployments.
- Handles high volumes of requests efficiently.
- Can be used for session storage and real-time applications.

#### **Cons:**
- Requires external infrastructure (Redis server).
- Additional latency compared to in-memory caching.

**Best For:**
- Large-scale applications needing persistent caching.
- API response caching, rate limiting, and session management.

---

## Cache Hits, Cache Misses, and Common Caching Gotchas

- **Cache Hit:** When requested data is found in the cache, resulting in a faster response without additional computation.
- **Cache Miss:** When the requested data is not found in the cache, requiring a database or API fetch, leading to higher latency.
- **Common Gotchas:**
- **Stale Data:** Cached content may become outdated if not refreshed properly.
- **Over-Caching:** Excessive caching can lead to inconsistent user experiences.
- **Under-Caching:** Not caching enough can lead to unnecessary server load.
- **Cache Invalidation Complexity:** Determining when to refresh cached data is often tricky and requires careful strategy.

---

## Choosing the Right Caching Strategy

![image](/caching-table.png)

## Final Thoughts

Caching is a powerful tool in Next.js for optimizing performance, reducing costs, and enhancing scalability. The right strategy depends on your application’s needs:

- **For static pages**, `getStaticProps` or ISR is best.
- **For dynamic but periodic updates**, use ISR.
- **For real-time updates**, SSR with caching is ideal.
- **For large-scale applications**, Redis caching offers flexibility and persistence.

By understanding and leveraging these caching techniques, you can significantly improve your Next.js application's speed and efficiency.

Do you have any preferred caching strategies? Get in touch below & let me know!
